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E: INTRODUCTION 


A. OVERALL GOALS 
Alvin Toffler, in his book The Third Wave, forecasts 
that future white-collar workers will be able to work from 


4 


home. "Home will become the center of society," but people 
will still "need face-to-face contact with each other to 
develop the trust and confidence necessary to work 
together." [TOFF80] 

With the capability of computer systems rapidly 
increasing, and the swift expansion of computer networks, 


these predictions are approaching fulfillment. Today this 


vision is materializing through the Software Framework for 


Tele-immersion (SOFT) project, National  Tele-Immersion 
Initiative (NTII), and Internet2. Their goals respectively 
are: 

alte SOFT 


The goal of the SOFT project is the painless 
introduction of networked collaboration into single-user 
computer graphics applications. The applications as well as 
the platforms they run on can be dissimilar. 

2. NTII 

The "NTE goal Es) to provide a rigorous: test Tor 


Internet2 and increase the degree of cooperation between the 


research laboratories involved. This will aid advances in 
virtual reality research [WEB1]. 
3% Internet2 


The goals of Internet2 are [WEB2]: 


e Enable a new generation of applications; 


e Create a leading edge research and education network 
capability 


e Transfer new capabilities to the global productia 
Interner: 


B. SCOPE OF THIS THESIS 

The scope of this thesis is the design and 
implementation of a network architecture for distribution of 
generic scene graphs. This network architecture provides a 
common graphical distributed environment for remote clients, 
which use various platforms. We examine the most effective 
structure to support this streamed communication between 
server and clients. Moreover, we investigate how Java-C++ 
server/clients can be integrated into the SOFT architecture. 
We examine multi-tier architecture and multicasting 
technology in order to transfer the vast amounts of data 
required for networked graphical applications. 

La Server Design 

SOFT will support distributed graphical applications 


collaborating freely a computer graphics client 


communities. Thus, the server must have the following 


characteristics: 


a) Multi-Client 

The client/server model can support relationships, 
such as one-to-one and One=EG-Many . The One>L O=many 
relationship refers to one client sending information 


through a server to multiple clients (multi-client). 


b) Multithread 

A thread is “a dispatchable unit of work.” 
[STAL98] Each thread is executed sequentially and can be 
interrupted so that a single processor can switch to another 
thread. Each process can be divided into threads able to run 
Simultaneously while executing an application. Moreover, all 
the threads can share the state and resources of the same 
process. This makes multithreading useful for applications 
that can execute independent tasks which do not need to be 
serialized. As a result, running multiple threads under the 


same process can result in less processor overhead because: 


e Thread creation requires less time than the creation 
of a new process; 


e A thread can terminate more rapidly than a process; 


e Switching between threads is less expensive. 


Figure 1 illustrates a multithreaded process model in 
which each thread has its own control block, user stack, and 
kernel stack, while sharing the same address space of the 
common process. An example of this model is a server that 


listens for and processes multiple clients’ requests. 
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Figure 1. Multithreaded Process Model [STAL98] 


c) Persistence 





Two different views of persistence are needed in 


the SOFT project: scene persistence and persistence binding. 


(1) Scene Persistence. The users in the 
client community will be able to make changes in their 
graphical environment. However, when they log out and log in 


again, they must see the scene as they left it. Thus, there 


is a need for scene persistence, which must be supported 


either in the server or the client. 


(2) Persistence Binding. When two applica- 
tions make a logical connection and are prepared to exchange 
commands and data, they perform a client/server mechanism 
called binding. The binding mechanism can be either 
persistent or nonpersistent. The SOFT server must be able to 
Support communication among multiple clients. These repeated 
calls must be maintained through persistent binding from the 
server side, which will keep the logical connection open as 
long as active clients are still in the system. 


2 Multi-Tier 

The term tier is used to "describe the. logical 
partitioning of an application across clients and servers.” 
[EDWA97] A two-tier client/server system exchanges 
information directly between a client and a server. In a 
three-tier architecture, an application layer between client 
and server exists (Figure 2). The three-tier architecture is 
less complex on the clvene Sidevand has high security; High 
data encapsulation, excellent Internet support, hetero- 
geneous resource management support, rich communication 
choices, flexible hardware architecture, and excellent 
performance. The middle-tier in the three-tier architecture 
is responsible for servicing requests and responses between 


the client and the server. 


Resource 
Managment 


Two-Tier Architecture 


Resource 
Managment 


RPC's, Queues, Broadcasts, etc. 


Three-Tier Architecture 


Figure 2. Multi-Tier Architecture [EDWA97] 





The middle-tier components are of two types: 


a) Services 


These are stateless procedures. 


b) Objects 
These have methods and can communicate across 
networks, operating systems, and languages. They are called 


Object Request Brokers (ORB’s) and support: 


(1) Stateless Objects. These do not 
have a unique state. Microsoft's Distributed Component 
Object Model (DCOM) is one example and Common Object Request 
Broker Architecture (CORBA) of Object Management Group (OMG) 


is another. 


(2) Stateful Objects. These use a 
unique object identifier in order to request services of a 
certain object. 
C. CONTRIBUTIONS AND GOAL OF THIS THESIS 
In a shared graphical environment with multiple 
clients, maintaining Eu same view for all clients networked 
together is generally the vital issue. Today, popular 
graphics libraries, such as OpenInventor, VRML, Java3D, and 
Fahrenheit use a scene graph as their main data structure. 
A client in a distributed graphical environment may wish to 
use any of these various scene graph implementations. SOFT 
envisions sharing via the scene graph. Each client is able 
to modify his or her own scene graph. Through network 
collaboration, this scene graph as bus metaphor provides the 


changes to other clients for a shared common view. The 


primary implementation contribution 9e tieers 1s the 
server, which efficiently allows for reliable messaging, 


occasional reduction 3n traffic, and persistent storage. 


D. CHAPTER SUMMARY 
The remainder of this thesis consists of the following 


chapters: 


e Chapter II: SOFT. We provide the objectives of the 
SOFT project, considering network collaboration and 
interoperability. We propose clients of SOFT, such 
as telecubicle, telesurgery, and generic sharing of 
standalone applications. Moreover, we present the 
logical architecture for the mapping layers of SOFT. 


e Chapter III: Related work. Here we evaluate other 
research related to and similar to SOFT projects. 


e Chapter IV: SOFT network architecture. Here we 
justify the use of the Java server and its 
centralized role. We also design the client side and 
provide a multicasting technique for the network 
architecture. 


e Chapter V: Server design and implementation. The 
methodology and the phases that followed in 
designing and implementing the server are discussed. 


e Chapter VI: Client side architecture and design. We 
provide the NSG protocol and its serialization. 


e Chapter VII: Empirical study of efficiency. Mé 
examine the overhead for the server ` and 
communication in example sessions. 


e Chapter VREr- We reach conclusions and make 
proposals for future work. 


II. SOFT PROJECT 


A. OBJECTIVES 

As stated by Brown University, the goal of the SOFT 
project is the painless aa lejano OT networked 
collaboration Into single-user computer graphics 
applications. The primary research goal is to determine 
those minimal alterations needed to integrate a stand-alone 
program neatly into a networked environment. 

Le Network Collaboration 

In a networked shared environment (Figure 3) each 
client is able to create his or her own objects and modify 
any other object, provided it has permission of the owner. 
Each new client, upon logging in, must be able to share the 
same view. Additionally, when the user selects an object on 
his image plane and brings it into his natural working 
volume, we must decide how this appears to an observer 
standing close by or at a distance. [PIER98] 

A graphical scene may contain various objects, 
different colors, objects within objects, different levels 
of detail, etc (Figure 4). These can be defined as a set of 
nodes organized into a set of hierarchies. The scene graph 
(SG) is the data structure “used to denote the entire 


ordered collection of these scene hierarchies.” [LEA96] 
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Figure 3 - Common Visual Environment 
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Figure 4. A Sample Scene of Paris and Its Corresponding 
Scene Graph [WEB3] 
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SOFT will provide the network framework for these SGs 
(GN. , OpenInventor, Fahrenheit, Java3D, etc.) to 
communicate. À graphical application using Openinventor will 
be able to make calls to another which uses Java3D as SG. 
Essentially this should lead to free collaboration in 
computer graphics client communities. The need for access to 
the application is vital in order to ensure consistency and 
atomicity in scene modifications. We trade programming 


Complexity for additional collaboration functionality. 


a) Layering 
Dividing SOFT into three logical layers reduces 


this programming complexity. The three layers are: 


(1) The Standard Scene Graph Layer (SSG). 
The SSG is the SG used by a specific application. Any 
extensions to the SSG will be contained as a sublayer in 
order to provide the functionality needed for the next 


layer, the mapping layer. 


(2) The Mapping Layer (ML). The ML provides 
the mapping between the SSG and the Network Scene Graph 
(NSG). AS we may have different kinds OL SSGs, 
architectures, and languages, a new ML has to be written to 


Support each desired combination. 


(3) The Network Scene Graph Layer (NSG). 
The NSG is a special abstract SG that is not displayed, but 


LL 


rather changes to it are mapped to changes in the SSG. The 
NSG is shared among all networked hosts in a SOFT session. 
It must contain data formats and contention resolution 
mechanisms. Additionally, it must specify the SG data 
semantics to be implemented in the mapping of the mapping 
layer. Thus, an API is used indirectly through the mapp ine 


layer. The SOFT layering is shown in Figure 5. 


SSG SSG 
(e.g. JAVA 3D) 


(e.g.OpenInventor) 


Network 


Figure 5 - SOFT Layering 


b) Sharing via Scene Graph 





The NSG is responsible for maintaining the same 
view for all the clients networked together in the same 


session. This is achieved as follows: 


e Each SG node maps its own set of 3D objects and 
o o Laos. 
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e The network layer uses the NSG as a bus metaphor to 
transmit the created or modified nodes to the remote 
client’s NSG; 


e The NSG of the remote client is then mapped to its 
own SG. 


B. PROPOSED CLIENTS OF SOFT 
SOFT aims to support any kind of distributed graphical 


application. Such applications can be, for example: 


e Telecubicle (office of the future, enhanced 
teleconferencing); 


e Medical Diagnosis and Telesurgery; 
e Surveillance; 
e Bomb Disposal; 


e Mining. 


We focus on the telecubicle because some industrial 
progress has been made in this area [WEB4]. Also, some 
Significant progress has been made in telesurgery, although 
it is too early for a commercialized product. 

I. Telecubicle 

As synthesized by Andy van Dam, a pioneer of graphics 
at Brown University, immersion and presence can be 
independent. People surrounded by panoramic views will feel 
immersion without presence. [DERT98] Telecubicle will be a 


new interface design of an office that can appear to become 
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one quadrant in a larger shared virtual office space. As 
shown in Figure 6, a telecubicle will consist of a stereo- 
immersive desk surface and at least two stereo-immersive 
walls. Projectors on the ceiling and various other points 
will render’ the images on the walls with ultra high color 
resolution (qe 500035000E Moreover, a telecubicle 


[DeFA98]: 


e Will be stereo capable without special glasses; 


e Will be networked to. teraf lop "computa Laia 
gigabit networking with low latency; 


e Will be available in a range of compatible hardware 
and software applications; 


e And will incorporate Al-based predictive models to 


compensate for latency and anticipate user 
transitions. 


Tele-immersive applications need to support nine 
distinct flow types [FOST98], which are shown in Table 1. 
Telecubicles will be linked to form a common work 
environment, demanding the previous flow of information. As 
shown in Figure 7, workers will be able to share virtual 
objects and data while having eye contact with each other. 
Henry Fuchs believes that “the ceiling lights are replaced 
by computer controlled cameras and ‘smart’ projectors that 
are used to capture dynamic image-based models with 


imperceptible structured light techniques, and to display 
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high-resolution images on designated display 


surfaces.” [FUCH98] 


Table 1. are ED of Tele-Immersive DM 


Em xm Ro 


A goal of telecubicle technology is to give the 










scientist, the engineer, and the worker the impression of 
collaboration. People will interact with each other through 
this mix of real and virtual environment - manipulating 
objects, experimenting, simulating, designing, amusing, and 


teaching. 
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Figure 8 shows the first four telecubicles that have been 


connected. [WEB7] 











Link to NASA AS 
Emphasis onfacial SFR 
sensing and X 

representation, and“ 


j link to CAVE, supercomputnes, and 
Gœ 












gorse on sonic elements. international research commuruties. 
kE Emphasis on cubicle design, 
app lication connectivity. 
~ L >. 

nn I. d software 

University of ` y H in EE Ann a u 

Illinois, : medical apriicatiaris 

„pChicago ; Yale University 








: user interface 


| E ec ; Columbia 
Bc b hi ERU ¿E ; University 


— A a 93 ; authoring tcols 
4 : Brown University 
Carnegie Mellon 





etivark 











Emphasis onn University 
research, user interface © 
> m r = sre resis, IL software, authoring. $000092000000000000000000000 000220 0000 22420000220 0902002292229 2aaaa 92225 < 
Yy and integration of 
; sensing and disp lay Link to worlds of education, 


Link to DARPA systems entertainment, other funders. 


University of Utah network design and research 
Integration mith po reseeeeeeeeeeencesaceeencennannennnnneriaannnnnannaanenanannaanannenna-se-annaananavaaanacoaceoneoceaceceeeceeeeeseeeeeora N 
physical part 7 Naval Postgraduate School ; 
fabrication , University ofUisconsin — Internet? 


Figure 8. The First Four Telecubicles [WEB7] 





Tele-immersive work stations, such as CAVE (Figure 9, 
[WEB8]), ImmersaDesk3 (Figure 10, [WEB9]), Totally Active 
Workspace (TAWS), and Personal Augmented Reality Immersive 
System (PARIS), have already been implemented  [DeFA98]. 
During her nomination as Indiana University's E 
Distinguished Visa tang Technologist in ES Advanced 


IMEOrMat bon Laboratory al Untvers_Lty, 'Protessor Donna J. Cox 
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described this process as “stepping inside the computer, 


because it widens the user's creativity and control 


[WEB10] .” 


Figure 9. CAVE [WEB8] Figure 10. ImmersaDesk 


[WEB9] 





2t Telesurgery 

A. Alexander in 1978 [ALEX78] was one of the first 
researchers to formulate the concept of telesurgery. "The 
driving force behind military interest in remote surgery is 
that 90$ of all deaths in wartime occur on the battlefield, 
before surgical care can reach the casualty” Voi io 7 |. 
Telesurgery can save the lives of isolated patients in the 


battlefield, rural areas, and aboard ship. 
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With telesurgery, the surgeon can perform surgery 
remotely (Figure 11, [WEB11]) using a special telesurgery 
console (Eaeure a WEB instruments (Figure 613, 
[WEB13]), and haptic devices (Figure 14, [WEB12]). 

But surgery usually involves many other people (other 
surgeons, medical staff, and observers) all needing to share 
information. These people must also share the same view in 
telesurgery. This can be achieved through the network 
collaboration between clients. Each can interact and 
Simulate face-to-face cooperation. The major components of 


telesurgery are [WEB14]: 


e Human Computer Interface (HCI); 
e Computer Assistance; 
e Communication Methods; 


e Telesurgical Worksites. 


SOFT could benefit the “communication methods” component by 
providing the networked collaboration among clients, and the 
HCI by providing an identical view to everyone. 
m Generic Sharing of Stand-Alone Applications 
Stand-alone applications, already written in popular 
scene graph implementations, should be able to use SOFT for 


networking capabilities with minimum effort. This will 
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increase reusability and performance 


applications. 
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Workstation [WEB12] 
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Es ARCHITECTURE 

Tele-immersion 1s likely the most technically 
enallénging aagvancead network application. Thus, considering 
interoperability and standardization, the architecture shown 
in Figure 15 has been chosen to support the previously 
identified nine distinct components to  tele-immersion 
anelprtcerture,ssuch as flow control; audio, video tracking, 


etc. 
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Figure 15. SOFT Architecture 
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r: SSG and Reporting 

SOBT is designed EO be independent of SG 
implementations. OpenInventor has been chosen as the primary 
SG, and Java3D and Fahrenheit will likely follow. 
Implementation has begun in C++ on SGI and SUN machines. SSG 
will be composed of nodes and fields with a unique 
identifier (ID fork each host mu sera report a 
modifications to the ML. Every modification requires locking 
for consistency purposes. 

2: Mapping Layer (ML) 

The ML is a single-base mapping layer between the SSG 
and the universal NSG. Being the interface between the SSG 
and the NSG, the ML accepts callbacks from the NSG. The ML 


behaves as follows: 


e Establishes top level reporting and defaults, 
initializing the NSG and network; 


e Recognizes SSG changes and serializes them; 
e Passes changes to the NSG; 
e Registers callbacks from the NSG; 


e Deserializes NSG information and reconstructs the 
respective SG nodes (special nodes with no analogy 
in the supported SG are simply ignored); 


e Passes deserialized SG nodes to the SSG. 
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The ML will require an API for locking objects on the 
network for editing. This API cannot be in the NSG layer 
because it must translate an SSG node to enable locking of 
the appropriate NSG node. 

3, Network Scene Graph Layer (NSG) 

The NSG maintains a common hierarchy of nodes available 
to the client community. Any ML modifications are mapped to 
the NSG and reported to the other clients. This is 
implemented through an API, responsible for exchanging 
information between the ML and the NSG. The NSG has the 


following structure: 


a) NSG Node 

A node is the fundamental element of a scene 
graph, such as separator, color, cone/sphere, etc. The NSG 
node supports any type of node. To do so, it contains 


certain fields. 


b) NSG Node Fields 


e Node type; 


e Unique identifier for the node, namely a node ID and 
a timestamp; 


e Unique identifier for the creator/owner of the node, 
1.e. the correspondent TE address and the 
Communicating Dore; 


e A set of contention flags. 
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E) NSG Field Contention Flags 

Proper handling of contention issues requires a 
network token/locking/check-out mechanism. The desired 
behavior is integrated into the system with the following 


flags to this pointTable2). 


Table 2. NSG Contention Flags 


Flag 


Distribute If (own object) Do not share writes 
Distribute locally 
Else 
Send to owner 


fecal edit Set vali on local 

oov P E 
reading network change 

Local callback Invoke a list of local No callback on 
callback when reading local change 
local change 

Remote callback | Invoke a list of remote No callback on 
callback when reading local change 


local change 





This architecture benefits in hiding network 
proprietary issues. Additionally, it gives the opportunity 
to various SGs to call each other, even over different 


hardware platforms. 
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4. Dial-a-Behavior Protocol (DaBP) 

Fundamentally, a protocol is used for exchanging data. 
This data exchange is a crucial issue in the SOFT 
architecture. Serializing and deserializing the exchanged 
data among clients over the network is a very cumbersome 
approach. With this approach, whenever there is a change in 
the data format of the exchanged data, the programmers must 
rewrite and recompile the application. For such a large 
project as SOFT is, flexibility was needed. This flexibility 
is provided through the DaBP, which provides methods to 
return the data from the network packets. 

The DaBP, developed at the Naval Postgraduate School, 
is currently implemented with Java and there is a C++ 
version under development. In this protocol, we must specify 
the field names and types of the exchanged data. This 
information is specified in a structured text file, using 
the Extensible Markup Language (XML), which is a 
reformulation of Standard Generalized Markup Me 
(SGML). XML is more powerful than Hypertext Markup Language 
(HTML), a standard SGML subset, because it can identify and 
process document structure and provide extensibility 
[SURV99]. Moreover, XML allows users to define their own 


tags and customize the way the protocol behaves. 
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DaBP is described with a predefined set of fixed tags. 
Each tag 1S uniquely associated with a specific field in the 
XML file. Beyond this, the protocol interpreter is 
responsible tom converting binary data into usable 
information. Consequently, with the use of this protocol, we 
achieve the required flexibility. Thus, the NSG layer does 
not have to serialize and deserialize the exchanged data. 
Instead, the NSG layer retrieves the data fields needed, 


querying the packets using DaBP methods. 
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III. RELATED WORK 


A. INTRODUCTION 

The spread of software systems, the expansion of 
networks, and the relatively low cost of graphics cards and 
their increased performance has generated the need for 
network collaboration among graphical applications. 
Additionally, the variety of important standalone graphical 
applications led developers to consider reusability and 
networking carefully. Concerning these two factors, the 


related work is divided into three areas of interest: 


e Interconnecting proprietary stand-alone 
applications; 


e Interconnecting heterogeneous virtual environ- 
ments; 


e Building frameworks For distributed virtual 


environments based on client/server approach and 
replication. 


B- INTERCONNECTING PROPRIETARY STAND ALONE APPLICATIONS 
The popularity of the Virtual Reality Modeling Language 
(VRML) used to describe 3D worlds established it as a 
language which developers could use tor graphic 
applications. The great progress in the presentation of 
stand-alone virtual worlds encouraged the VRML community to 


implement multiple worlds and users to interact with each 
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other. This progress was made possible by the network 
capabilities OT the Java language, which provides 
appropriate and efficient communication mechanisms. 

Wolfgang Broll presented an approach in “Supporting 
Multiple Users and Shared Applications with VRML” [BROL97]. 
He exhibits a network infrastructure and appropriate 
mechanisms to partition the virtual worlds. He uses a 
multi-user daemon, which provides reliable TCI ae 
connections in order to download shared virtual worlds. To 
overcome the problem of inconsistency between shared worlds, 
the daemon retains incoming events and transmits them to new 
clients after the transmission of the basic virtual world 
has been completed (Figure 16.) After the successful 


transmissions, the TCP/IP connection is closed. 


Multi-User 
Daemon 
(2)aWorldi connects 


and events 


(1) Connect 
tO wora 


New. T T PIT 
Group 


(3) New connection 
to be established 


Figure 16. Connecting to a Virtual World 
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The multi-user daemon acknowledges all events sent by 
consecutively numbered messages. The sender resends all 
messages that haven't been acknowledged. A unicast 
connection is used for receiving the missing messages. To 
avoid the multi-user daemon bottleneck caused by unicast 
connections, additional server daemons may be used. However, 
to avoid slowing down the performance of multi-user daemons, 
all the additional servers require access to the multicast 
group. 

Usually, in a large-scale virtual environment, the 
client needs to participate in only a portion of the world. 
Recording to "Bro the*selution is\ to subdividemune world 
in regions and link them through mechanisms that do not 
interfere with user navigation. Thus, only currently visible 
parts of the world need to be updated, reducing the network 
traffic. Broll’s approach exploits the VRML Region node. 
Moreover, he uses the VRML User node and the VRML Avatar 
node to limit user interactions in the shared virtual 
environment. Each user has a personal VRML file, which is 
transmitted by the local browser to all the participants and 
the central daemon. In this way, each participant has his or 
her own individual scene graph. Furthermore, shared 


behaviors and interactions between clients are required. 
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Broll identifies four general classes of shared 


behaviors: 


e Autonomous behaviors (e.g. a clock, a blinking 
tight) 


e Synchronized behaviors (e.g. a bouncing ball, a 
TOMOS SEI SING 


e Independent interactions (e.g. a button to ring a 
bell); 


e Shared interactions (e.g. avatars with a single 


region where the behavior is described within this 
single region). 


He represents these shared behaviors and interactions 
with nodes. Behavior nodes receive and send events. Finally, 
he uses synchronization and locking mechanisms for the 


events. 


e INTERCONNECTING HETEROGENEOUS VIRTUAL ENVIRONMENTS 
Capps et al. in their work "Distributed Interoperable 
Virtual Environments" present the use of a software bus 
(Polylith) as a utility to compose existing applications 
instead of modifying them [CAPP96]. They focused on the 
issue of interoperability between different graphic software 
applications that run on different hardware platforms. They 


assumed that next generation virtual environments will not 
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depend on specific languages and hardware. Furthermore, they 
were concerned about reusing software components. 

Based on these issues, they used a Polylith software 
bus as a connection module, capable of listening to a 
variety GE event classes and handling them both 
simultaneously and asynchronously. They built an event- 
listener as a central intermediary that can serve all the 
components in the virtual reality environment. This 
intermediary provides the “glue” for interconnecting the two 
different virtual reality applications. 

This software bus encapsulates decisions concerning the 
interfacing of modules instead of distributing them among 
the participants. Thus, there is only one responsibility for 
mapping each domain into the abstract bus specification. 
Then developers for either side can easily use these 
asstraclions within thelr conLigurarrons. 

These researchers conclude that the same collaboration 
issues used in shared editors and workspace environments 
apply in multi-user virtual environments. These can be 
exploited by software bus modules that provide for the 


mapping between the interconnecting domains. 
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Dr BUILDING FRAMEWORKS FOR DISTRIBUTED VIRTUAL 
ENVIRONMENTS BASED ON A CLIENT/SERVER APPROACH AND 
REPLICATION 
We present the following three different approaches 

using a client/server mechanisms and replication: 

1: Community Place (CP) Architecture 
Lea, Honda, and Matsuda in their work “Community Place: 

Architecture and Performance” [LEA97] presented a 

client/server system where a central server is responsible 

for sharing a VRML scene. Participants connect to this 
server in order to load the VRML file that is responsible 


for rendering the shared scene. The basic architecture is 


shown in Figure 17. The order of actions is: 


e The Community Place (CP) browser loads the 3D data 
file (VRML format); 


e The CP browser contacts the server via the Virtual 
Society Client Protocol (VSCP) that runs above BR 


e The server informs the CP browser for other 
participants. 


The VSCP runs above TCP and ensures connectivity. It 
has an object-oriented packet definition allowing 
applications to’ extend the) basic ede cc acto with 
application specific messages. Thus, VSCP ensures exchanging 


of script level messages that permit browsers to share 
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events and therefore support shared interaction with the 3D 


Scene. 


Application 
Objects 


Authentication 
Server 


Voice Chat 


Replicator 
P Server 


Server 


CP Browser 
(Java) 


CP Architecture 





Each user navigating through the scene sends position 
information to the server. Using area of interest 
algorithms, the server decides which other browsers a user 
needs to be aware of. The server need not know information 
about the scene loaded by the browser. 

Lea, Honda, and Matsuda introduced the idea of a Simple 
Shared Script (SSS) model mechanism, which is responsible 


for downloading the same script and executing it locally. To 
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deal with issues such as ownership and persistence, they 
added the notion of a master browser to the SSS model. 
Whenever the master browser is selected by the server, it is 
told that the master has been selected. Scripts are capable 
of sending events to other browsers. In cases where the user 
wants to implement serialization as a scene object, it is 
done via the master browser. Afterwards, the master browser 
distributes the changes. 

For more complex situations, they introduced the idea 
of an Solis er Object (AO) which exists externally to the 


browser and the server. This AO consists of three parts: 


e The 3D data description that represents the 
application in the shared scene; 


e The associated scripts that accept user input and 
communicate back to the AO; 


e The AO side code that implements the application 
NOCHE 


The AO allows the creation of 3D objects dynamically 
during run-time. The applications use the Virtual Society 
Application Protocol (VSAP) to register their applicati omi 
objects with the server. 

They use a spatial model to reduce network traffic 
among participants who share a 3D scene. Their communication 


mechanism is based on multicasting. 


34 


2. Spline Architecture 

Another approach for building these frameworks is the 
Spline architecture used for the Diamond Park Virtual 
Reality System designed by the Mithubishi Electrical 
Research Laboratory (MERL) [WEB15]. Spline’s world model is 
not a scene graph but rather an object-oriented database 
supporting visual and audio information. The objects have 
ownership attributes to avoid reader/writer conflicts. The 
ownership of an object can be transferred from one process 
to another. Spline’s objects do not persist over time. 

This architecture is based on replication so that each 
world model resides in each application process. Focusing on 
the issue of speed Spline provides approximate equality 
between world model copies. Users are grouped together in 
locales of interest. Each locale is associated with a 
separate multicast communication channel avoiding 
propagation of messages to uninterested participants. A 
hybrid communication approach was proposed for the Spline 
3.0 version where client/server communication will be point- 
to-point and server/server communication will be peer-to- 
peer multicast. The exchanged messages are divided into 
small rapidly changing objects, large slowly changing 
objects, and continuous Streams of datas In Splaneese0, Jana 


will be the primarily high level interface. 
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on Repo-3D Architecture 

Blair MacIntyre and Steven Feiner in their paper “A 
Distributed 3D Graphics Library” present Repo-3D, a general 
purpose object-oriented library for developing distributed, 
interactive 3D graphics applications across a range of 
heterogeneous workstations [MACI98]. According to them, from 
the programmer’s viewpoint, objects reside in a large 
distibuted shared memory (DSM) instead of a single process. 
The underlying system is responsible for replicating the 
objects among the processes. Simple, remote, and replicated 
are three types of distributed objects semantics in DSM. 

Since the refresh rate is a crucial factor in 
interactive-graphics virtual-reality applications, the data 
needs to be local to the process doing the rendering. Repo- 
3D uses the Columbia Object-Oriented Testbed for Exploratory 
Research in Interactive Environments  (COTERIE) as the 
replication mechanism because neither Inventor nor Java3D 
provides support for distribution. 

The CORBA solution was rejected for being too 
heavyweight and for not supporting replication. Java proved 
to be more suitable for the implementation language because 
of its cross-platform compatibility and support for theese 
and garbage collection. The Repo-3D architecture is shown in 


Figure 18 where distributed data sharing is provided by two 
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packages, the Network Object client/server object package 
and the Replicated Object shared object package. 

Distanim-3D is derived from Anim-3D, a powerful, non- 
distributed, general purpose 3D graphics library. Anim-3D is 
a scene graph model suitable to a distributed environment. 
In Anime-3D, properties are attached to nodes and any 
changes do not affect the result. Unlike Inventor, ordering 
1s not necessary. Properties are only inherited down the 


graph. 


DistAnim-3D 


Objects 


i 
Network Objects Native Graphics 


|J Replicated | | 


Modula-3 Runtime 


Operating System Services 


Network 


Figure 18. Repo-3D Architecture 
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The Network object package provides support for remote 
objects. This package is similar to Java’s Remote Method 
Invocation (RMI). The Replicated Object package of course 
Supports replicated objects. Each process can call any 
method of an object it shares. This package follows the 
principles of atomicity and serialization of an object. 

Repo-3D rationale provides programmers with the 
illusion of a large shared memory using Distributed Shared 
Memory (DSM), making it easy for them to prototype 
distributed 3D graphics applications. Their future work will 
most likely use Java because even if Java does not support a 
replication object system, the JSDT may be a fine starting 


Point: 


E. CONCLUSIONS 

Our SOFT architecture has both similarities to, and 
differences from, the presented approaches. Like CP, SOFT 
uses a centralized server. 

Its architecture doesn't depend on a particular scene 
graph (Inventor is used as an example of a scene graph 
implementation), as the ML is responsible for mapping any 
scene graph to the NSG. SOFT differs from Spline and CP 
because it stores scene graphs using Java native structures, 


instead of an object oriented database. Moreover, SOFT 
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doesn’t depend on any database replication mechanism, as 
Spline does. Furthermore, instead of distributing VRML 
files, like CP Or Broll’s architecture does, SOET 
distributes scene graphs. 

Lastly, unlike Repo3D, which is based on COTERIE for 
the underlying distribution of scene graphs, SOFT invokes 


Java networking methods and is capable of using RMI. 
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IV. SOFT NETWORK ARCHITECTURE 


A. INTRODUCTION 

Noe) OULl Med = In T en Virtual = environment 
fesecarencrs = ==are  “atuccMpEingu to = solve the “problem = of 
networking collaborative virtual environments with various 
architect-ures. Some developers use multicast groups, others 
try to solve the problem using replicated databases, and a 
few others use hybrid techniques. According to Michael Zyda, 
replicated world databases are more efficient than 
centralized or distributed shared database schemes, but they 
generally lack a way to maintain world consistency 
[2YDA97]. Also, large virtual environments could use hybrid 
models with small replicated data sets and a distributed 
client/server model. Thus, the client/server module could be 
integrated in such environments. 

Thinking of implementation, we considered .that Java 
provides innovative methods for building virtual worlds. 
Furthermore, since our primarily goal was to maintain a 
common shared view, and no database or replication 
capability existed, we decided to design and implement a 
centralized server using Java. Below, we present our 


decision and provide more details. 
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B. SERVER 

We chose to implement the SOFT network architecture 
using a centralized server. This server would be responsible 
for providing a common share view among clients. Below we 
present both our justifications for the centralized server 
and the use of the Java programming language. 

qu Justification for Centralized Server 

First let us examine the rationale for our decision to 
implement the centralized server. Our decision was based on 


the following criteria: 


a) Reliability 

Several data exchanged in a tele-immersion session 
must be sent reliably. This is required in order to ensure 
consistency of the world database or to reflect an accurate 
update from a simulation or user interface event. [FOST99] 

As stated in Chapter II, a major aim of SOFT is to 
provide a common graphical distributed environment, where 
each client must be able to share the same view. This means 
that every action on any client must be broadcast to all the 
other clients concurrently connected. Moreover, users must 
be able to collaborate using the available objects. Object 
use must have the permission of the owner and thus a 


universal locking mechanism must exist. The use of a 
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centralized server facilitates all these transactions. 
Clients notify or query the server in order to create, 
modify, or use an object. The server is responsible for 
storage, Foci mG, and broadcasting to the currently 
connected users (Figure 19). 

The only drawback is that this kind of implement- 
ation is based upon the reliability of a single server. Any 
failure of this server will affect the common shared virtual 


environment. 


b) Scalability 

Usually a Server creates a bottleneck, an 
ündesireable factor in- terms -of scalability But MSsSing 
multiple servers, we can overcome the bottleneck and 
increase the scalability. Furthermore, multiple servers can 
be used in conjunction with the Reliable Multicast Transport 
Protocol (RMTP). RMTP uses receivers associated with local 
regions or domains. In each domain, there is a special 
receiver, called a designated receiver (DR) [PAUL98]. 
Additionally, a special client can also be a server during a 
session, called a designated server (DS) (Figure 20). 

A centralized server implementation may reveal 
potential problems that could be spread in a networked 


collaborative environment. Fortunately, the centralized 
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server implementation can isolate and solve these problems, 
providing a more robust scalable module that can more easily 


be integrated in the previously mentioned architecture. 


E) Persistence 

The status of the objects in a virtual environment 
varies according to the indication of their contention 
flags. Some objects will vanish when their owner disconnects 
from the system, while others may remain until their owner 
deletes them, even if the owner is not currently logged on 
the system. 

With a centralized server, storing the contention 
flags and providing the necessary persistence is easy. Also, 
objects can be independent from client existence and can be 


retrieved easier from a centralized server. 


d) Latecomer Support 

When new clients join the virtual environment, 
they must be aware of all the currently existing objects. 
The server can store and maintain the current status of 
every object which is present in the environment. Also, 
whenever new clients connect to the network, the server 
sends them all the available data. Thus, the new client 


becomes a member of the common virtual environment. 
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e) Conclusion 
The centralized server implementation has some 


drawbacks such as: 


e Network bottleneck through which all traffic must 
pass; 


e The environment depends on the reliability of a 
single machine. 


But the benefits are: 
e Simple and clear implementation; 
e Universal locking mechanism; 


e Can be used as a scalable module to serve a domain 
in a more complex implementation; 


e Easier storage/retrieval mechanisms used to provide 
persistence; 


e Latecomer support. 


Since the benefits provide a flexibility which is more 
important in the current state of the project, we chose the 
centralized server implementation. 

2c Justification for Java Server 

In Chapter III, the derived conclusions focus mainly on 
Java implementations. Since the working prototype had been 
developed in C++ with UNIX as the operating system, we had 


to chose between C++ and Java. Below we present our criteria 
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and analysis which resulted in Java being chosen for the 


implementation. 


a) Built-In Standard Libraries 

Java contains standard libraries for solving 
specific tasks [ECKE98]. These tasks include networking and 
multi-threading, which are major aspects of the server 
implementation. Using standard libraries promotes rapid 
development time allows us to focus on the specifications 
and requirements for the server. On the other hand, C++ 
relies on third-party non-standard libraries or on code from 
scratch. Development is time consuming and involves higher 
risk potential. Moreover, Java standard libraries support 
database connectivity via JDBC and distributed objects via 
RMI and CORBA. These features are not of immediate value, 
but they enhance the scalability and flexibility of the 


project in the future. 


b) Garbage Collection 

Memory management during the server session is a 
factor dramatically affecting robustness. Java provides a 
built-in mechanism for memory management called garbage 
collection [CHEW98]. Garbage collection is responsible for 
non-referenced memory release so that it may be reused. This 


way memory-leaked-addresses are corrected, and explicitly 
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deallocating memory is not needed. Note, however, that a 
memory leak can still exist if unused memory remains 
referenced. Memory management is a critical factor for the 
server because there iS a permanent “read a stream into a 
buffer, store the data, release the buffer” loop. 

Robust memory management may affect performance 
too. According to Bruce Eckel, overall, Java could possc. 
be as fast or faster than C++ [ECKE98]. This can happen 
because, even though interpreted Java code can be even 20 
times slower compared to equivalent compiled C++ code, the 
new-delete mechanism for memory management in C++ leaves 
holes in the heap eventually making it slower. The 
allocation mechanism has to seek available space through 
those holes in order to prevent running out of heap storage. 
This searching may seriously decrease performance. The Java 
garbage collector rearranges memory, allowing the high- 
speed, infinite-free-heap model to be used while allocating 


storage. [ECKE98] 


c) Platform Independence 

Java programs are compiled to an architecture- 
neutral byte-code format [FLAN97]. These byte-codes can be 
interpreted by the same version or newer Java Virtual 


Machine (JVM) on any platform. Platform independence is a 
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real benefit for the SOFT server as it allows users to use 
SOFT without purchasing new hardware or installing a new 


operating system. 


d) XML, Java and DaBP 

As stated in Chapter II, XML is quite powerful. It 
provides a S d schema or metadata mechanism for 
defining, understanding, and interchanging files and data 
between two systems [SURV99]. XML is already being used by 
the DaBP. We intend to examine the feasibility of 
incorporating DaBP in the SOFT architecture. Moreover, “Java 
is on the XML action both as driver and utilizer of XML 


capabilities." [SURV99] 


e) Evolution - Maintenance 

The SOFT project is an evolving environment, and 
major modifications are likely in the future. Every 
modification or improvement may affect the server also. A 
Simple Java server will require less effort and time to 


update than a C++ implementation. 


£f) Conclusion 
The built-in standard libraries for networking, 


the garbage collection mechanism, the platform independence, 
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the cooperation with XML and DaBP, and the easiest way to 


maintain the system prompted us to employ Java. 


E: CLIENT SIDE 

In the SOFT architectures, the client “can” “bean. 
standalone application (graphical or not). Every client must 
be able to exchange information among other clients 
transparently. Therefore, SOFT must provide an API for the 
upper layers of its architecture. 

ES API to Network 

The client provides an API for the mapping layer core. 
This makes the network layer independent of the SSG 
implementation. The methods available to the mapping layer 


include the following: 


e Initialize the network; 

o Set and get per-typed callbacks; 

e Serialize data into a single NSG node; 

o Get a list of nodes; 

° Map from name to NSG node; 

* Set and get global callbacks; 

o Get and set local root of the scene graph; 
e Set, get, and call end of frame callbacks; 
o Get list of roots of remote scene graphs. 
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2. Client High-Level Architecture 

The client is an abstraction that provides network 
access to the mapping layer of the SOFT architecture. It is 
independent from the SSG and can be used by different 
graphics applications. It is not hardware specific and 
handles large and little-endian issues, providing inter- 


operability. The client has been implemented in C++. 


D. MULTICASTING 

One of the most common ways of communication is one-to- 
one. The client-server model falls into this category. 
Another category is unicast communication where the web 
client retrieves information from the web server. A third 
example is broadcast communication, for instance radio and 
television where each client tunes to a certain frequency to 
retrieve information. Multicast falls between unicast and 
broadcast and “is a one-to-many communication” [PAUL98]. 

When providing the same data for multiple graphical 
applications in the client community, multicast transmission 
is needed, rather than repeated unicast transmission to each 
receiver [FOST99]. In this way, the sender can transmit a 
Single copy of a packet, regardless of the number of 
clients. The routers in the network infrastructure are 


responsible for delivering the packet to the clients. The 
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packet is replicated as many times as the number of clients, 
which improves the efficiency of the network use. 

The multicast data can be in a variety of forms: audio, 
video, haptic device streams, and tracking. The size of the 
data, especially the video, can be enormous in size per 
second. Thus, latency plays a key role in the sharing of a 
common graphical environment among the client communities. 
So far, the use of multicasting has two drawbacks, which 


actually do not rely on multicasting itself: 


e Difficulty in accessing high-performance multicast 
enabled networks; 


e Lack of middleware tools with access to multicast. 


Based on the reliability and the latency requirements, 
the multicasting applications are divided into three 


categories [PAUL98]: 


e Interactive applications; 
e Streaming applications; 


e Reliable multicast applications. 


The relationship between latency and reliability is 


illustrated in Figure 21. 
For many applications, despite the issues QE 


reliability and latency, there is a basic need for selective 
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Eee ıbutıon. This means only a certain group or clients 


must receive the information. 
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Figure 21. Categories of Multicast Applications 
[PAUL98] 
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V. SERVER DESIGN AND IMPLEMENTATION 


A. INTRODUCTION 

In the SOFT architecture, the server must support 
multiple clients, latecomers, and use the DaBP. The client 
Side could be any standalone application. The server must be 
responsible for providing the clients a common shared 
environment. In order to analyze and understand the previous 
work done, we had to follow a methodology under a strict 
time frame. We present the methodology used to accomplish 


this and the way the server was implemented. 


B. METHODOLOGY 

When we were engaged in the SOFT project, a working 
prototype existed. This prototype consisted of two modules, 
a server and a client, working together as a pair. Both the 
client and the server had been implemented in C++ on Silicon 
Graphics machines running UNIX. This prototype provided a 
two-way communication between the client and the server 
(Figure 22). The server and the client were running 
OpenInventor and rendered a simple cone. After establishing 
a communication channel, each one (the server and the 


client) was responsible for delivering its own scene graph 


D 


to the other. At this point, both were able to render a 


synthetic image consisting of each other’s cone (Figure 23). 





Client 





Figure 22. First Working Prototype 


In this prototype, OpenInventor was used as the SSG and 
reporting mechanism. The ML layer was provided through 
separate functionality, specifically designed for the 
OpenInventor implementation. The NSG layer was also separate 
and provided the above communication functionality. Our 
objective was to augment the functionality of the first 


prototype and to design a server module with: 


e` Multi Clrent Functionality 
e Latecomer Support; 
e Persistence; 


e Locking Mechanism. 
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Before establishing communication: 


After establishing communication: 


Figure 23. Synthesizing a Common Environment 


According to Schach, some popular software life- 





cycle models are: 


ABU TUE amd Ein; 

e Waterfall; 

e Rapid PTOUtOGU pang: 

e incremental; 

e Synthesize and Stabilize; 
e Spiral; 


e Object Oriented. [SCHA99] 


p 


Having the above working prototype as a basis and 
considering timing limitations and involved risk, we decided 
to use the spiral model. The spiral model corresponds each 
cycle to a phase. As shown in Figure 24, we used the working 


prototype as a core, and we gradually progressed to phase 


Lives 


Figure 24. Spiral Model Implementation 
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Es PHASES OF DEVELOPMENT 

We developed the application in five phases. We present 
in each phase below, our objectives and the derived 
conclusions that provided us the feedback to continue onto 
the next one. 


1, Phase One 


a) Objective 

In order to examine the feasibility of such an 
independent mechanism, our objective was the intervention of 
a client/server mechanism between the existing pair of 
client and server (Figure 25). The benefit from this was a 
better understanding of the working prototype and the format 


of exchanged data. 


b) Implementation 

This intervening mechanism was implemented in Java 
1.2 on Windows NT 4.0, as shown in Appendix A. The UML 
documentation of this phase is shown in Figure 26. The new 
intervening mechanism was a hybrid client/server system 
consisting of two modules - the Java client/server module, 
and the original C++ client/server module. The reason for 
this was to emulate painlessly the current client/server 


mechanism. 
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Implementation | 
Java Client AQ cH Client | 


Figure 25. Phase One 





The server C++ module started the execution of a 
graphics application. Following this, the Java server and 
the Java client started. The Java server waited to be 
invoked by listening to the Java and Ct+ clients using TCP 
sockets. Once this communication had been established, the 
Java server waited for the C++ client requests. Upon 
request, the Java server opened the communication channel 
with the original C++ client and sent the data. Then, both 


of them had a common view of the scene. Whenever the server 
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or the client made modifications to its own respective 
scene, these modifications were automatically transferred 


through the network and reflected to the other. 


server actor | client actor | server _| clientthread | client thread... | serveOne | serveOne:...| 
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Figure 26. UML Sequence Diagram (Phase One) 
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c) Conclusions 

In this phase, we introduced seamlessly an 
independent client/server mechanism A the existing 
prototype, while maintaining the same functionality. We 
examined the exchanged data format and were able to build 
our own server. 


2% Phase Two 


a) Objective 

In this phase, our objective was providing a 
single-server mechanism between two equivalent existing 
clients (Figure 27). The benefit of this was forming a new 
independent server-mechanism. This mechanism was the basis 


for the new implementation. 


Jor Java Server 


CS: C++ Server 


CC: C++ Client 


Figure 27. Phase Two 
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b) Implementation 

We improved the phase one prototype, as in 
Appendix B. The UML documentation is shown in Figure 28. 
Then, we created the  "ServeOne" class as a thread 
responsible for opening a connection between two predefined 
C++ clients. Once the connection was established, the thread 
was reading the input stream from the CS client and was 
writing the output stream to the CC client. We also created 
the Server class, responsible for initiating the ServeOne 
thread. 

The CS initiated a new session. Then the JS 
connected to CS and waited for the CC client to connect. 
eon” Tne. CE. connecerTen, the uni-directional [SE WW OF 


information from the G++ server (CS) to C++ client (CC). 


c) Conclusions 

We successfully excluded the Java client 
implementation from the intermediate server module of Phase. 
One, managing to maintain the same functionality. This 
simple server module provided scalability for the next 


phase. 
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3. Phase Three 


a) Objectives 

Our objectives were to establish a bi-directional 
communication and to provide a storing/retrieving mechanism 
for the NSG messages communicated via the server (Figure 
EI This storing/retrieving mechanism demanded a 
deserialization of the NSG messages. Thus, we would be able 
to gain scalability for the next phases. Additionally, we 
would be able to examine the effectiveness of such a 
mechanism because the existing client implementation 


required the message retrieval in a specific order. 


S 


Hash Table 


Client Client 


Figure 29. Phase Three 
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b) Implementation 

First, we modified the server in order to interact 
with only CC clients. The server listened to CC clients to 
connect. Upon their connection, the server initiated two 
threads, one reading the input stream of the first client 
and writing to the output stream of the second, and vice 
versa for the second thread. 

Second, we provided the server with a hash table 


implementation as the storing data structure. 


static Hashtable htable = new Hashtable(); 


Moreover, we implemented the method: 


public void parseStream(byte[] buf, int len) 


as a deserialization mechanism in order to get the unique 


identification (ID) of each received message and store it to 


the hash table (Figure 30). 


) 


(TE 
Identification 


Figure 30. Parsed Stream 
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We chose the Hashtable Java implementation because it 
guarantees O(log(n)) time cost for the get, put, and remove 
operations. Moreover, the Hashtable is synchronized [WEB16]. 
According to this unique ID, the message was either inserted 
into the hash table (if the ID were a new one) or modified 
an existing one (if the ID already existed in the table.) 
Appendix C contains complete implementation. The UML 


documentation is shown in Figure 31. 


c) Conclusions 

We managed to establish the bi-directional 
communication between two clients. Additionally, we 
stored/retreived the exchanged data in the hash table. In 
this manner we maintained a common-shared-view among the 
clients. As this shared view was stored in the hash table, 
we were ready to provide latecomer support in the future 
implementation. 

During the testing, we discovered that having 
stored the messages in the hash table, we were unable to 
retrieve them in the specific order required by the existing 
C++ client implementation. Consequently, we concluded that 
in the next phase we had to change the hash table data 


structure used for storing and replace it with a dictionary. 
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4. Phase Four 


a) Objective 

Craw a Wie Was Loros e lento inet. OMe limi, 
to the server (Figure 32.) The benefit from this was 
latecomer support and persistence. Latecomers would be able 
to retrieve the common environment from the storing 
mechanism. Since the hash table proved to be inefficient 
during Phase Three, we had to replace it with a more 


appropriate one. 


Client 


Client 


Server 


Client 


= Hash Table & Client-Pool 


Figure 32. Phase Four 
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b) Implementation 


First, we added a client-pool 


static Vector castTable = new Vector(); 


to store the currently running clients. In the castTable, we 
stored the DataOutputStream of each client. Thus, every new 
message could be retransmitted to all the clients in the 
pool. 

Second, we provided latecomer support, where each new 
client received all the stored messages. Following this, we 
replaced the storage data structure (hash table) with a 


dictionary: 


public class NSGRepository extends Dictionary 


Since the dictionary is an abstract class, we decided 
to implement it using vector. Despite its time cost of O(n) 
for t get; PUE, and remove, we gained the required 
functionality of retrieving the records in the order we 
needed them. This was a temporary solution, as the clients 
would not require an ordered set of messages in the future. 

Third, we provided multi-client Support. The server 


entered in an endless loop where it accepted every new 
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client, creating a new thread to support it. The new thread 
waswwesponsible for up-loading the existing envuironmenteewee 
the client so that each shared a common view. After this, 
the new thread started to read from the InputStream of the 
client and to write to every OutputStream existing in the 
client pool. The complete implementation is presented in 


Appendix D. The UML documentation is shown in Figure 33. 


c) Conclusions 

We managed to store the exchanged messages in a 
dictionary storage data structure. Consequently, we provided 
latecomer support and persistence. Furthermore, we were able 
to function in a multi-client environment. 

On the other hand, we concluded that the parsing 
stream mechanism was able to process only a limited set of 
message types (e.g. primitive shapes and transformations.) 
Therefore, we identified the need for an independent 
mechanism able to read formated messages rather than simple 


byte arrays requiring deserialization. 
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5% Phase Five 


a) Objective 

Our goal was to provide the ability to read 
formated data from the InputStream of each client. The idea 
was that the server should be unaware of the type of 
transmitted WAGGA EE but still be able to dynamically 
process and store them. This would give better scalability 
and would make the server implementation less proprietary. 


As a result, we examined the feasibility of using DaBP. 


b) Implementation 

Since DaBP requires the use of XML files for 
reading the format of the protocol, we created a sample XML 
file as in Appendix E pacc NE for the representation of 
the transformation message. The transmitted messages are 
called Abstract Data Units (ADUs), and they are structured 
according to the protocol. 

We also created two sample Java clients (with no 
graphical interface) because the C++ clients were not mature 
enough to be invoked in a reliable testing procedure. The 
Java implementation of these clients can be found in 
Appendix F. These Java clients simulated the real clients by 


sending and receiving messages using DaBP. 
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The server Was responsible for CyucaminGmmne Protocol: 


ProtocolDescription protocol; 


protocol = new ProtocolDescription(“SOFTexp.xm!”); 


and each thread was responsible for establishing a stream 
for reading using the ADUStreamTCP class, which reads one or 


more ADUs transmitted across the TCP socket. 


ADUStreamTCP tcpStream; 
Socket in_ socket; 


tcpStream = new ADUStreamTCP(in_ socket, protocol); 


Next, the thread was able to read from this stream 
using an ADUData class. This class represents data received 
from the network in the protocol defined format. Appendix G 
contains the complete implementation. The UML documentation 


is shown in Figure 34. 


74 


NSGServer NSGServeOne run 


client actor 


server actor 


er 


wer 


r 


lient_a 


T 


wer 3 





v 2 
E v 
Jem 3 S 
> 
PIS a > t 
= d d £ £ 
à 
SI lS : 2 9 
o o 
t L al y : Bla 
sa a o A o CENE am lllo e oen Es ni: A ee 
5 2 3 
E y y 9 
a t v A 
v a Y 
% O t 
3 r €. t 
a > o 
5 a = b 
o 4 c 
ef]: : 
^" " ö 
y E v 
6 O v 
a 
v 
v = $ Y 9 
o 3 = 
3 o c v E v 
€ o e v e o 
= c " v q m Q 
v a c x 
2 y ~ v v æ 
v N 3 € 9 c v 
Y = e > a E e 
v n a o 9 a 
qe -- v = 
n" = © + o v 
v c o & M 
5 = R / 9 
o 
* o a) = = a =f | io EE) eee © eases van ccec cca scecssiccancws a descnsiciewinsls cisacildcces} ecidliescicsiseeces ee 
y 
= 3 
c 
% y 
a 
@eqdeerreeeeeeeneeeeeeeeevrenee+eeeecu 9 
cas aaa colla esse T A 


eeeeerseeneneanee0 
e"ecc"ocoo "o" "oneonPCC"""n»"o"Oveto9 9 n0.0000000099090000949999900000000099 800 999^ 09900*9202909909090909009209200-0999—.0009090909299999999^99999099902902n90909099090929 


"0-222222 


(Phase Five) 


F 
U 
D 
d 
“4 
Q 
Y 
U 
G 
Y 
p 
0) 
un 
E 
(Y) 
Y 
4 
b 
E 
Iu 





75 


c Conclusion 


After examining the feasibility of using the DaBP, 


we conclude that: 


DaBP integrated and cooperated efficiently under ene 
current architecture; 


DaBP provided the necessary flexibility for the SOFT 
project because instead of a stream parsing 
mechanism, we could directly access the fields of 
the ADUs; 


DaBP uses XML, which is derived from the ISO 
Standard Generalized Markup Language (SGML), 
cooperates with Java, and provides scalability for 
future implementation; 


DaBP is worth being evolved and included in the SOFT 
architecture. 
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VI. CLIENT SIDE ARCHITECTURE AND DESIGN 


A. NETWORK SCENE GRAPH (NSG) PROTOCOL 

The NSG protocol is an information exchange mechanism 
between the network layer and the ML. This information is 
the scene graph appropriately modified and serialized in 
order to provide platform independence across the network. 
Each NSG is owned by one host at a time. Specifically, it is 
composed of nodes and fields. A node consists of: 

L: UID 

The UID is a úniquùue identifier for the node; consisting 
of a combination of owner ID and time of creation. A UID is 
required because we may have multiple clients running on the 
same host. 

2. NSGtag 

This defines the type of the node. Different nodes with 
the same tag may have different type signatures. Once the 
node has been created, the type signature is not changed. 
Setting NSGtag only during node creation enforces this 
policy. 

SOFT provides a base set of tags (Table 3) which every 
SOFT implementation can interpret. The application and the 
user may define any new tags they wish, ones which are not 


implemented yet. The tags of Table 4 have already been 


a7 


designed. Tags are sent as text strings roughly equivalent 


to notations in a mark-up language. 








M 






Table 3. Implemented NSG Tags 
Contains an array of “noderef” UlDs. The 
NSG uses left-right/top-down inheritance 
(as in OpenInventor) instead of top-down 


NSGsep_node 
inheritance as used in Java3D and FSG 


NSGcolor node Contains a NSGfield vec3 [rgb] 
NSGxform node 


NSGcone_node A cone centered at (0,0,0) that goes from 

nt SO eine Senn ae Tone 

Noceube mode A cube centered at (0,0,0) that goes from 
=] tO +1 in each dimension. 

A cylinder centered at (0,0,0) that goes 
from -1 to +1 in each dimension. 

A sphere cn eed a E 
From l to Fin each. dimension 


















Table 4. Designed NSG Tags 










The number -of tristrips. A rr Crip 
contains two arrays of three vectors 
[position, normal] and two vectors 
[texture coordinates] and an int[size] 


Material Material properties such as emisSive, 
Texture Texture images [contains a URL to the 
Ken 
LIGNE A light object (enumerated such as, 
Camera Viewport mapping (aspect ratio, etc.) 


near, far, position, focal distance, typed 
orientation 


FaceSet Indexed face set: array of three vectors 
[points] and array of ints. 


Contains a double [alpha] 


Array of 
Tristrrps 
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3. Owner 

phis term identifies uniquely the creator omWowner of a 
node. The owner is stored as an IP address and port for 
communicating updates. 

4. Contention Flags 

Each node has a set of independent Boolean flags for 
handling contention. The flags have default settings in the 
IE 0.27 Any complex sort “or contention control- requires 
dropping to a callback. Certain callbacks, which are used 
frequently in combination to provide desired behavior, are 
integrated into the system as flags (Table 2). 

5: Fields 

A field is one of the static, non-extensible sets of 


enumerated primitive types listed in Table 5. 


Table 5. NSG Fields 


NsGevela double IEEE 64 bit floating point number 
Nessie ld 32 bit signed integer 
NSGfield string String of ASCII characters 







NSGfield vec3 Three doubles 
NSGfield noderef A node UID 


NES AiO ae net A-non-default-traversed reference to a 
node, in UID format 





A runtime-variable-length array of any of the preceding 
eyees 
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If an application does not provide a traversal behavior 
for a given tag, then the behavior is changed to traverse 
any and all *noderef” fields of the node, according to thelr 
order. Consequently, the point of an “ntnoderef” is that it 
allows a user-defined tag node to reference another node 
without being traversed by applications that clones 
understand the tag. 

The node UID and the owner are required to solve 
contention issues arising during modification of a remotely- 
owned object. The ordered list of types of the fields of the 
node is called the "type signature" of the node. Different 
nodes with the same tag may have different type signatures. 
Once a node has been created, the type of signature cannot 
be changed. A more detailed description of the NSG node is 


shown in Figure 35. 


B. NSG SERIALIZATION/DESERIALIZATION 
All the NSG information is encapsulated in a byte 
array. This byte array is actually transmitted over the 


network, It consists of: 


e An integer that indicates the length of the byte 
array; 


e The body of the message, which carries on the same 
Toce 
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NSGxform_node NSGcolor_node 
E pend NSGfield. list A e Ur Em PT CE ERN RR 


*NSGcolor_node(const NSGfield_list &!, const NSGname &name) 
“tagd : NSGtag & 

“static make(const NSGfield_list &, const NSGname &name) : NSGnode * 
*get( : NS6vec3 

*unset( : void 

eSel(const NSGfield vec3 &s) : void 


O non IN ajin 











&old xf : NSGfield xform & 

@xform( : NSGfield_xform & 

Spending xf : NSGfield_xform & 
*NSGxform_node(const NSGfield_list &I, const NSGname &name) 
ViagO : NSGtag 8 
Static make(const NSGfield, list &I, const NSGname &name) : NSGnode 

















*set(const NSGfiled_xform 8 : void 
*unset() : void 

Ymake_pending( : void 

Yget_pending() : NSGfield_list & 

*get( : NS6mat & 

Static cast(NSGid node) : NSOxform node * 


IAS à 0:8 
NSGsep node Su 
ST "acce pu c 52 T VE 


$NSGsep node(const NSOfield list &l, const NSGname &name) 

*tagQ : NSGtag & 

*static make(const NSGfield_list &!, const NSGname £name) : NSGnode 

*unset() : void 

*set(const NSGfield_noderefs &s) : void 

*get() : vectorsNSGnode *, alloc» & 

Static cast(NSGid node) : NSGsep, node * va 
LE 


A A ua 
NSGcube_node TZ EN 


*NSGcube. node(const NSGfield, list &I, const NSGna 















NSGcyl node 


Ken 

> NSOnode | <H PNSGcyi_node(const NSGfield_list £l, const NSGname ¿name) 
ETA | *tag((argname) : NSGtag & 

ON > *static make(const NSGfield_list 81, const NSGname &name) : | 






















*tag( : NSGtag & 
*static make(const NSGfield, list &I, const NSGna 


NSGcone node NSGsphere node 





*NSGsphere node(const NSGfield_list &, const NSGname &name) 
Yago : NSGtag £ 
Static make(const NSGfield list &I, const N56name &name) : NSGnode 











*NSGcone_node(const NSGfield_list &, const NSGname &name) 
$tag() : NSGtag & 
static make(const NSGfield list &I, const N56name &name) : NSGnode * 



















Figure 35. UML Documentation for NSG Node 






The serialization is implemented overloading the "««" 


operator. According to Meyers, the purpose of operator 
overloading is that it is easy to read, write, and 
understand [ME YES Likewise, deserialization is 


implemented overloading the “>>” operator. During the 


8l 


deserialization process, the byte array is broken into its 
individual parts. This architecture provides scalability 
because the implementers can seamlessly add new data 


structures: 
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VII. EMPIRICAL TESTING 


A. INTRODUCTION 

A shared virtual environment with many clients requires 
low communications latency. We examined the overhead of our 
centralized server implementation in a uni-directional data 
exchange between two clients, both with and without the 
DaBP. 

For experimental purposes, we implemented two specific 
clients: a sending client (Sclient), and a receiving client 
(Rclient). A sample packet was used to simulate the exchange 
of a generic transformation between the two clients. When 
DaBP was used, the packet was created from the XML file. 
Without DaBP, the packet was a sample packet taken from the 
transmission of a real SOFT client. The clients and server 
ran on an Intel-based computer vc Windows NT4.0. The 


client implementation can be found in Appendix H. 


B. TESTING SERVER OVERHEAD WITH DABP 

In this experiment we tested the server’s overhead 
involving the DaBP. We transmitted 1,000, 5,000, 10,000, 
50,000, 100,000, and 120,000 packets. The results are shown 


in Table 6. According to the results, as the number of 
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packets increases the timing cost per packet increases from 


Pees) Ms to 6.88 ms? 


Table 6. Average Server Overhead with DaBP 







Packets Transmitted Timing Cosey 







packet 


e TESTING SERVER OVERHEAD WITHOUT DABP 







In this experiment we tested the server’s overhead 
without DaBP. The results from the experiment are shown in 
Table 7. The results reveal a timing cost fluctuating 
between 6.023 ms and 6.162 ms per packet. The server’s 
overhead is independent from the number of packets 


transmitted.: 
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Table 7. Average Server Overhead without DaBP 





Packets Transmitted 





Mimo 
Cost/packet 


D. PROBLEMS TESTING WITH DABP 


















During the experimental session, we encountered some 
problems using DaBP. First, we were unable to install it 
properly due to hardcoded absolute paths. Thus, we inserted 
our own absolute paths to make it work. Second, the String 
data type was not supported. We tried to substitute String 
with arrays of unsigned bytes, without success. In order to 
solve this problem, we created fixed-length byte arrays. 
Third,- during packet transmission null pointer exceptions 
were thrown. Our first assumption was a buffer overflow, 
which led us to increase the size of the input and output 


buffers without result. The problem was solved by replacing 
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the InputStream with DataInputStream and the read method 
with readFully. Finally we discovered a memory-leak problem, 
which significantly reduced its performance for large number 


of packets (over 50,000). 


E. CONCLUSIONS 

Performing a trend analysis (Figure 36) we discovered 
that using DaBP gives significant performance enhancement 
(approximately six time speedup) when the number of 
transmitted packets is small (less than 50000). When the 
number of packets increases, the server’s overhead is 
increased, due to memory-leak problems of the DaBP. The 
parsing of byte streams iS a much more time consuming method 
than extracting the necessary information of a previously 
formatted-with-DaBP message, but it has a neutral behavior 
to the number of packets transmitted. The previously 
discussed problems do not remove DaBP as a viable candidate 
for integration into the SOFT architecture. But, it needs 
further implementation and extensive debugging in order to 


become a stable product. 
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Figure 36. Trend Analysis with/without DaBP 
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VIII. CONCLUSION AND FUTURE WORK 


A. INTRODUCTION 

This thesis designs and implements a network 
architecture for distribution of generic scene graphs. We 
concentrated on the design and implementation of a 
centralized server that supports multiple clients, providing 
them with a common shared environment. The results are 


intended to be incorporated into the SOFT project. 


B. CONCLUSIONS 

We built a centralized server using Java that provided 
reliability, persistence, scalability, and latecomer support 
in a multi-client SOFT environment. This server provides 
interoperability and can support any SSGs on any platform. 
We concluded that this implementation demonstrated the 
benefits of the DaBP. 

Empirically testing the server overhead, we discovered 
that using DaBP reduced the overhead by a factor of six for 
less than 50,000 packets. The performance and flexibility of 
DaBP indicates that it is worth the effort to extend it to a 
stable Produce: and incorporate it into the SORT 


architecture. Of course, empirical testing to confirm 
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performance improvement for large number of packets must be 


conducted. 


e FUTURE RESEARCH IDEAS 

The goal of the SOFT project Is network collaboration 
between computer graphics applications. These applications 
can be implemented in vari languages over different 
platforms. SOFT clients are currently implemented in C++ on 
UNIX platforms. They use OpenInventor as the Standard Scene 
Graph (SSG). In order to fulfill the objectives of the SON 
architecture, the implementation must be extended to include 
other platforms (e.g., Intel-based), languages (e.g., Java), 
and SSGs (e.g., Java3D). 

As stated in Chapter IV, the SOFT server can be part of 
a topologically larger network environment. In the 
environment, various clusters can have their own server 
modules. Furthermore, the clients have been implemented 
separately from the server. Merging the server and the. 
client modules would be ideal. This new module would act 
either as a server and/or as a client. This would mean the 
module could take turns being a server, and whenever the 
—Ü module left, it would migrate and transfer duties. 

The current implementation of the SOFT client “and 


server modules requires an ordered procedure. Specific 


20 


programs must be invoked and executed using command line 
methods. A user interface could be built in order to act as 
a SOFT session manager. 

Currently, the DaBP library is limited. For instance, a 
limited set of data types is supported (e.g., integer, 
float.) Additionally, the libraries are prototype versions 
and contain errors. In the future, DaBP libraries could be 
improved and completed resulting in a mature product. Since 
DaBP provides flexibility, it can be extended to include 
designs of application-specific protocols that can be 
changed based on network load. 

The feasibility of using multicasting technology for 
the distribution of generic scene graphs should be examined 
as multicast hardware ES more widely available. Also, 
the use of multi-tier architecture, like CORBA and COM, can 


be exploited under the SOFT architecture. 


D. SUMMARY 

The SOFT project approaches networking collaborative 
virtual environments these environments with the use of the 
scene graph as bus metaphor. This networking has been 
rein anes with centralized servers responsible for the 


distribution of the scene graphs. This shared visual 


environment is the first stepping stone towards networking 
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client communities. Later goals of SOFT include sharing of 
entity behaviors and actions, and will be addressed in 


follow-on work. 
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APPENDIX A - JAVA CODE FOR “PHASE ONE” 


5 nn E e 
// Filename: Server.java 

// Date: ¿USOS 

// Compiler: JDK 1.2 

A A AAA A A e = SS O 


Import. jJava.net.”; 
ImporE java.ıio.*; 


/** 
* Server for "Phase One". Creates a client/server mechanism between 


* the existing pair of SOFT client and server. 
* 


* (author P.Fiabolis,G.Prokopakis 
y 


public class Server { 


/* 
* Main function 
* 


* (param args: Command line arguments 
* @exception IOException 
2 
public static void main (String[] args) throws IOException { 


ServerSocket s = new ServerSocket (9999); 


ServerSocket is = new ServerSocket (8099); 
Syseemeout.-prinelmijsersc nresterteea Se 
System.out.println("Local server started: " + is); 


InetAddress addr = InetAddress.getByName ("royal"); 
new ClientThread(addr); 


System. out.printin("Coennection with master startede. i 
Socket in socket = Iis- accept ():; 
Bey t 


while(true) { 
Socket socket = s.accept(); 
EME 
System: out. printint slave ro M 
new Serveone(sockeut anu sceker), 
) 
catch (IOExceptiomete 1 
System.out.println("Server.main: IOException"); 
socket.close(); 
) 
y // end while 
) 
finally 1 
s.close(); 
is.close(); 
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) // end of main() 
) // end of class Server 


// end of file Server.java 


O as 
// Filename: ServeOne.java 

// Date: 20-April-99 

Y Compiler: JD > 

Lea e E O E OO eee 


import java 10.7; 
import java.net.*; 


+ 


% 
Thread running for each connection. A simple client/server 
mechanism, reading from the input stream and wrighting to 
the output stream. 


* * ++ + 


x 


@author P.Fiabolis,G.Prokopakis 
Er 
class ServeOne extends Thread { 


/** 
* Socket of the current thread. 
=) 

private Socket socket; 


/** 
* Stream to read from. 
* / u 


DataInputStream in; 


/** 
= SOs put Stem 
E 
DataOutputStream out; 
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y 
EC lassoconstructor 
* 


* (param s: Socket for output 
* (param in socket: Socket for input 
* @exception IOException ; 
7 
publie SserveOne(Socker Ss, Socket in socket) throws IOException 1 
socket = S; 


in new Datarnput credn e ock. eSgeclnputStream T 
out = new DataOutputStream(s.getOutputStream()); 


start)? 


) // end of ServeOne 


/* 
* Thread main loop. Performs the read/write operation until 
elent are disconnected: 
* 
i 
Publiesvora runi) 1 
byte[] buf = new byte[1024]; 
int len = 0, tmp = 0; 


try í 
while(true) { 


CEY 
len = in.readInt(); 
in.readFully(buf, 0, len); 


out.writelnt (len); 
out write (buf,20, leni: 
} 
catch (IOException e) { 
Systemoout.printlin('"Cannceb' reacae Ji; 
) 
) 


} 
finally { 
// Always close it: 


CENH 
socket. closet 


catch (IOException e) { 
: System.out.println("ServeOne.run: IOException"); 


} 
} 


y // end of run() 


y // end of class ServeOne 
// end of file ServeOne. java 
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// Filename: ClientThread.java 


// Date: 20-April-99 
ZA Compiler: TJIDK I2 
ff a E 


APO Java. Meters 
import java:io. ; 


/** 
* Thread implementation of the internal client module. 
* This module reads from the C++ SOFT Server, and writes 


* to the Java server module. 
* 


* @author P.Fiabolis,G.Prokopakis 
*/ 
class ClientThread extends Thread { 


/** 
* Socket of the current thread. 
zy 

Private sockerzsocker. 


/** 
OULPUE SOCKEL. 
T 


pare Soc SiO TM AS Oe Ke, 


/** 

PS Steed tO eee 
2 

DataInputStream data in; 


/** 

* Output stream. 

1 
Dataoutpütstreamtdatca out; 


/* 
"OcPuSS Cosme 
* 
* (iparam addr: Inet address where this client should connect 
x 
public ClientThread(InetAddress addr) { 
System outs printin( Makina cliente 
A! 
socket = new Socket (addr, 8080); 


InetAddress self = InetAddress.getByName ("127.0.0.1"); 
out socket - newdSocket sel ro DU EN 


) 
catch (IOException e) ( 
// If the creation of the socket fails, no need for cleanup. 


} 


tr 
data in = new DatalnputStream(socker-gerInpurser au NM 
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data Ones = new 
DapdeMEDUtStream(out socket.getOutputStream()); 
Startí); 
) 
catch (IOException e) { 
// The socket should be closed on any failures 
// other than the socket constructor 
iT 
Socket.close(); 
SUtESeCKet, close): 
} 
catch (IOException e2) { 
} 


x 
* Thread main loop. Performs the read(from C++ server) /write 


* operation until the clients are disconnected. 
* 


E 


mubpiyc vweid run() f 


byte[] buf = new byte[1024]; 
int len = 0, tmp = 0; 


Gry 4 
while(true) { 
ERA 
Sn > ra a e 
data in.readFully(buf, 0, len); 
dat IT 
data out.write(buf, 0, len); 
) 
catch (IOException e) { 
oysStem.ouUt.printüinc Cannotereade c e 
} 
} // end while 
} 
finally f 
// Always close it: 
ELSA 


Socket.close(); 
GUETSOCKGE.c lease”, 
} 
catch (IOException e) { 
} 
} 


|o omdess runi) 


) // end of class ClientThread 
// end of file ClientThread.java 
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APPENDIX B —- JAVA CODE FOR "PHASE TWO" 


MA 22-2227 77-222 - = - 
// Filename: Server.java 

// Date: 04-May-99 

compiler: JDK 1.2 

1 1 --7777777272222222222222222222222277777 7 - 


import java.net.*; 
BIBorc-Java.1io0.*; 


per 

* Server for "Phase Two". Performs the read/write operation 
* between a C++ SOFT server and a C++ SOFT client, without 
* needing an internal client module. 

* 

* @author P.Fiabolis,G.Prokopakis 

7 


public class Server { 


/* 
Malo L£unectlon 
* 


* @param args: Command line arguments 
* @exception IOException 
A 
NA static void main (Stringí] args) throws IOException { 
new ServeOne(); 
) // end of main 


lay end or Class Server 


// end of file Server.java 


= = = zn Te 
// Filename: ServeOne.java 

// Date: 04-May-99 

// Compiler: JDK 1.2 
E sea ee ane a 


import Java.ıo.*; 
import java.net.*; 


/** 
* Thread running for each connection. A simple client/server 
* mechanism, reading from the input stream and wrighting to 


* the output stream. 
* 


* author P.Fiabolis,G.Prokopakis 


29 


x 
class ServeOne extends Thread { 


/** 
"Sockets roDbOreadddpnemy ucc 
MA 
private Socket in Socket MONCI SOC ker, 


/** 
* Server Socket for the connection of the CF client. 
w 


private ServerSocket Server socket, 


v= 
* Stream to reacwrron: 
e 

DataInputStream in; 


/** 
TOU Stream. 
a 
Data0utputstream out; 


/* 
a l aSS CONSCrUCCOr 
Ae 


* @exception IOException 
A 
public ServeOne() throws IOException { 
Server socket — new Serverococken: (Suu 
InetAddress addr = InetAddress.getByName ("royal"); 
in socket - new Socket(addr, 9999); 


in = new Datalnpueseream (in seckee, deb inputs a), 


out socket = server socket ec E 
out = new Data0utpurstream(outzspeker ge tSureir ter an 


start): 


* Thread main loop. Performs the read/write operation until 
* the clients are disconnected. 


my 
pubiiie verdzrun 4 
byte[] buf = new byte[1024]; 
int len = 0, tmp = 0; 


Ery A 
while(true) { 


Cry i 
len = in.readint(); 
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in:readFuliy (buf; Q0 len); 


out.writelnt (len); 
out.write (but, 0, len); 
} 
catch (IOException e) { 


E Sremscoubsprintin("Cannot read s 
) 
) 
) 
ponas nl 
// Always close it: 
Eo v 


tpsOcket. close: 
CUCM oe recelos, 
Scheer, cce close e 


) 
catch (IOException e) ( 


) 
) 
) // end of run() 
) // end of class ServeOne 


// end of file ServeOne.java 
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APPENDIX C — JAVA CODE FOR “PHASE THREE” 


a LLL. SS SS SSS SS E LL.LT1A2/ 
// Filename: Server.java 

// Date: 03-June-99 

E ompiler: JDK 1.2 

ff n R E 


import java.net. *; 
import Java. Lo. 


/** 


* Server for "Phase Three". Performs the read/write operation 
* between two C++ SOFT clients. 

* 

* @author P.Fiabolis,G.Prokopakis 

E 


public class Server | 


d X 

* Main function 

* 

* @param args: Command line arguments 
* @exception IOException 

27 


public static void main (String[] args) throws IOException { 


if(args.length != 3) { 
usageMessage(); 
System.exit(0); 

) 


String server mame — orgs Mi 
io da e oe tel 


Socket InSSOcket, Sur Socket, 
InetAddress addr; 


TEVE 
server Socket - new ServerSocket(Integer.parseInt(args[2])); 
in socket TLIE 


InetAddress client addrl = in socket.getInetAddress(); 


System.out,.printIn(’"ClVenrzfoung er 7; 
client _addrl.getHostName()); 


“OUT socket = server socket accepi k 
InetAddress client addr2 - out socket.getInetAddress(); 


System.out.printinisclrent como 
eltent addrz.getHostiame (s 


ry i 
new ServeOne(in socket, out socket, “SOFT client 1“); 
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new ServeOne(out_sockét, in socket, "SOFTEN S; 


System.out.println(Thread.activeCount()); 
while(Thread.activeCount() » 1) { 
) // end while 
) 
finally =i 
CEV 
in SOC ke tre lese (a, 
OULTSOCKOL COSI 
) 
catch (IOException e) ( 
System.out.println( Couldarnot  elosetsoske 
) 
) 
) 
catch(IOException ie) { 
System.out.println("Server problem"); 
System.exit (0); 
) 


] end “ot marn 


/* 
* Provide help message if the command line arguments 
"Mare not valida 
* 
E 
public static void usageMessage() 1 
System.out.print("Usage: java Server <server name>"); 
System.out.println(" <server port> zeilgene Port- i) 
System. Uranio 
System.out.println("Exaple: java Server venus 9000 8000"); 
System.out.println("\tvenus - machine running the SOFT server"); 
System.out.printin("\t9000 - venus machine port”); 
System.out.println("\t8000 = client mache score oe 


} // end of usageMessage 
) // end of class Server 


// end of file Server.java 
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// Filename: NSGStreamRecord.java 


// Date: 04-May-99 

I D cGsmp»sler: JDK 1.2 

Lud a a a mer 
/** 


* Implementation of a record to be stored by the SOFT server. 
* 


* @author P.Fiabolis,G.Prokopakis 
#7 
class NSGStreamRecord { 


/** 
* Unique key for the message. 
i 

String key; 


/** 
* Message as it was received from the network. 
P 

byte[] data; 


Class constructor 


Gparam id: Message ID 
Gparam len: Message length 
* @param record: Original message 
P 
public NSGStreamRecord(byte[] id, int len, byte[] record) { 
key = new String(id, 0, len); 
data = new byte[65535]; 
data = record; 


+ + +++ 


) // end of NSGStreamRecord 
) // end of class NSGStreamRecord 


// end of file NSGStreamRecord.java 
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APPENDIX D - JAVA CODE FOR “PHASE FOUR” 


LCS cc a A A SA SR A O E 
// Filename: NSGServer.java 

// Date: 18-June-99 

7 CompilessesJTDK 1.2 

A A cL o 


import java.net.*; 
IMPOrt Java-10.*; 


/** 

* Main class for the NSG server. Enters an endless loop waiting 
* for client requests. 

* 

* @author P.Fiabolis,G.Prokopakis 

27 


public class NSGServer { 


SAD mainm unction. 


* @param args: Command line param. Should have the port number. 
* @exception IOException 
4 
public static void main (String[] args) throws IOException { 
if(args.length != 1) { 
usageMessage(); 
System.exit (0); 
} 


SCIVErSOCcketzscetverssocker, 
InetAddress addr; 


int counter = l; 


Cry ont 
server socket = new ServerSocket (Integer.parselnt (args[0])); 


Wee 
SoOCKet in Socket- "Server socket. acecor 


addr = in socket.getInetAddress(); 
System.out.println("Welcome " + addr.getHostName()); 


try { 
new NSGServeOnelin socket, scounter++) 
} 
catch (IOException e) { 
in Socket close (E 
} 
\ /7 end whale 
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catch (IOException e) { 
system.out.printin("“Gannot anitialize server) Exiting. ."); 
System.exit (0); 

) 


KA F/Senña of main 


7E 
* Message to display in case of invalid command line arguments. 
* 
En 

public static void usageMessage() { 


System.out.println("Usage : java Server «port number»"); 
System- out- print in 
System.out.println("Example: java Server 9999"); 

} // end of usageMessage 


) // end of class NSGServer 


// end of file NSGServer.java 


11-2 a 
// Filename: NSGServeOne.java 

// Date: 18-June-99 

// Compiler: JDR I2 

q a E A 


Import sda van o 

import java.net.*; 

import java.util.Hashtable; 
import java.util.Enumeration; 
import java util Vector, 


/** 

* An instance of this class is running for every client connected to 
the 

* NSGServer. 


* 


* (author P.Fiabolis,G.Prokopakis 
r 
class NSGServeOne extends Thread { 


ix 

* Unique ID for each thread. For the moment this is a simple counter 
n 

int threadID; 


/** 
* Stream where this thread reads from 
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Er 


DataInputStream in; 


/** 

* Stream where this thread will write the NSG's stored in the 
repository. 

d 


DataOutputStream me; 


/** 

* Table holding the ports for all conected clients. Common for all 
threads 

ur 


Static Vector castTable - new Vector(); 


/** 

* Table holding SG data sent from clients. Common for all threads 
2% 
static NSGRepository table = new NSGRepository(); 


/** 
* Semaphore for thread exit. 
ll 


boolean stopThread = false; 


/** 

* Socket associated with this thread. 
mU 

Socket threadSocket; 


/* 
* Class constructor 
* 


* (param in socket: Socket for this thread connection 
* (param id: unique ID for this client. For the moment just a counter 
* @exception IOException 
ah 
public NSGServeOne(Socket in socket, int id) throws IOException { 


thħhreadID = id; 


tire cdas o SiS Dele 


in new DataInputStream (in socket.getInputStream()); 
me = new DataOutputStream(in socket.getOutputStream()); 


// Add the new Comer to rne elın list. 
castTable.addElement (me) ; 


Steart (); 


) // end of NSGServeOne 


/* 
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* Thread main loop. Runs until thread needs to be alive. 
A 


E 
public vord rune 
int ten =U; 


DataOutputStream out; 


// Send the data (if any) from the repository to the newcomer. 


yy oA 
Enumeration enum = NSGServeOne.table.elements(); 
while (enum. hasMoreElements()) { 
NSGStreamRecord s = (NSGStreamRecord) enum.nextElement () ; 
if (s.threadID != threadID) { 
System.out.printlia( TAB MRS ken 


byte[] tmpBuf = new byte[65535]; 
tmpBuf = s.data; 
me.writeInt(s.dataLength); 
me.write(tmpBuf, 0, s.dataLength); 


me.flush(); 


) 
) 
cotchorOEXxcebotron e) { 
System.out.println("Thread stopped. Connection with "| 
threadID + " farled.")- 
closeThread(); 


) 
while(!stopThread) { 
Er 
len = in.readInt(); 
byte[] buf = new byte[len]; 
in.zreadkeully(bur io, zen): 


// Send the message to everyone 
Enumeration enum = castTable.elements(); 


while (enum.hasMoreElements()) { 
ý out = (DataOutputStream) enum.nextElement (); 
if (out != me) { 


out.writelnt (len); 
OUUC Write (bur, o, len): 
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) // end while 


// Store or update the data. 
parseStream(buf, len); 


) 

catch (IOException e) { 
System.out.println("Goodbye " + threadID); 
closeThread(); 


} 
} // end while (!stopThread) 


Ber sendeorsrun 


/* 
* Close the thread after finishing connection or failure 
* 
P7 
public void closeThread() { 
ia Ve 


threadSocket.close(); 
castTable.removeElement (me); 
stopThread = true; 
} 
catch (IOException e) { 
System.out.println("ERROR: Could not close socket @ 
closeThread"); 


) 


Wena tor releosethresd 


* 

* Parse data received from the network and store them in an appropriate 
* repository. Data for existing objects are been updated. 
* 
* 


@param buf: Byte array send from the client. 
* (iparam len: Length of the byte array. 


public void parseStream(byte[] buf, int len) { 
byte[] buffer = new byte[65535]; 


buffer = buf; 
BYCCArraVinputstream Dyte: stream, 
Datalmpürstream datastream 


int dataLen = len; 


int headerLen; // Size of data header 
int nameLen; // Size of NSG node name 
int keyLen; // Length of unique key for this data 


ee 


ine lenLett; 
int bytesToRead; 
byte[] tmp_buf = new byte[65535]; 


// Create a new stream just to break it and extract the NSG ID. 


byte Stream = Mew wey CeArray I npu Ercan ou ne, 
data stream = new Datalnputstream(Di ten- o- ome 


ery 
bytesToRead = data stream.readInt(); 
len = len - 4; 
if (bytesToRead == 4) { 


// Read in header 


headerLen - data stream.readInt(); 


len = len - 4; 
data stream.readFully(tmp buf, 0, headerLen); 
len = len - headerLen; 


string header = new Strimg(tmp Bucle a dente” 


"Read inenocde same 

nameLen ="“data stream.readint(); 

len = len - 4; 

datasseream. reaqdnulty (Emp out, . © TT 


if (!header.equals("NSGnew")) { 
// This record doesn't describe a NSGnode, so make a 
// key by concatenating the header with the "key" (node 


name) 
String name = new Seeing (tmp out, 20, nsmeben)r 
String final key = header + "|" + name; 
tmp buf = final key.getBytest); 
keyLen = final key.length(); 
) 
else { 
keyLen = nameLen; 
) 
NSGStreamRecord stream rec = new NSGStreamRecora(tmpybury 
keyLen, buffer, dataLen, threadID); 
Object val — table.put(streamWrec Key istream reci 
SYSTEM, OUL, Print ln (Stream see weve, 
if (val == null) { 
System.out.println(threadID +L ": New record added."); 
) 
else { 
System. Out. printin(threadi pe) = Record founds. 
updated."); 
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} 
else { 
System.out.println("ERROR: No recorded message. Length = " 
bytesToRead + " @ parseStream."); 
} 
} 
catch(IOException ie) { 
System.out.println("ERROR: Problem reading integer € 
parseStream."); 


) 


} // end of parseStream 
y // end of class NSGServeOne 


// end of file NSGServeOne.java 


"ccc IIIS EN a LL Lm LLL 
// Filename: NSGStreamRecord.java 

// Date: 18-June-99 

A Compiler: JDK? 
ee a 
/** 


* NSG record. Stored in the NSGRepository. 
* Should be modified to match the appropriate structure of the NSG. 
* 
* Bauthor P.Frabolrs,G-Prokopakzis 
* 1 
class NSGStreamRecord { 


/** 

* Uniqe key of the NSG 
2, 

Sering key? 


/** 
* Byte array. It is stored as it is read from the client. 
ir 

byte[] data; 


sik 2 

* Length of the byte array (data). 
Er 

int dataLength; 


/** 

* Thread that this NSG came from. Used in order to avoid retransmiting 
this back. 

a 


IT3 


> 


int threadID; 


/* 

» Class COnSErUCHOr: 

* 

* @param recKey: Unique ID of the NSG. 

* @param keyLen: Length of the key. 

* @param record: Byte array aS it is read from the client. 
* @param dataLen: Length of the byte array (record) 

* @param id: Thread ID. 


= 


public NS6GStreamkecord(bytefjTreckey, ineskeyLen, bytel) record Pus 
dataLen, int id) { 


key = new String(recKey, 0, keyLen); 


data 


U 


new byte[65535]; 


data record: 
dataLength = dataLen; 
threadID = id; 

} // end of NSGStreamRecord 

} // end of class NSGStreamRecord 


// end of file NSGStreamRecord.java 


NS O SS SO 
// Filename: NSGRepository.java 

// Date: 18-June-99 

// Compiler: JDK 1.2 

77 0 


import Java utiles; 
import java. Loma, 


+ 


N 


* xoxo ko oko 


Implementation of the data structure where NSG's are stored. 
For the moment a Vector is used in order to provide NSG's 

to the new comers in the order they have arrived. 

This is going to be replaced by the TreeMap class (jdk 1.2). 


@author P.Fiabolis,G.Prokopakis 


— 


public class NSGRepository extends Dictionary { 
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/** 
* MEStor to store the keys of the NSG's. 
E 

private Vector Keys - new Vector(); 


/** 
* Vector to store the byte arrays (data). 
27 

private Vector Values = new Vector(); 


pe 
* Gives the number of the contents of the repository. 
* 
= 

publac int size() f 


return Keys.size(); 


} 


JE 
* Check if the vector is empty. 
+ 
7 
public boolean isEmpty() { 
return Keys.isEmpty(); 


) 


8 
* Insert a new NSG record in the repository. 
* 
* @param key: Unique ID of the NSG. 
* @param value: NSG record to be stored. 
7 
public Object put (Object key, Object value) { 
if(Keys.contains(key)) { 
int index = Keys.indexOf (key); 
Values.setElementAt (value, index); 
return key; 
} 
else ( 
Keys.addElement(key); 
Values.addElement(value); 
return null; 


* Get the record of the NSG with ID = key. 


* @param key: Unique ID of NSG to look for. 
ur 
public Object get(Object key) { 
int index = Keys.indexOf (key) ; 
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index ==" 1] 
return null; 
) 
else { 
return Values.elementAt (index); 


) 


f= 
A REMOVE the record of toeo Catan D aa Sc 
* 
* @param key: Unique ID of NSG to be removed. 
Y 
public Object remove (Object key) { 
Object retVal; 


int index = Keys.indexOf (key); 


if(index == -1) ( 
retVal = null; 

) 

else ( 
Keys .removeElementAt (index); 
retVal = Values.elementAt (index); 
Values.removeElementAt (index); 


} 


return retVal; 


/* 
* Provide an Enumeration data structure for the keys Vector. 
* 
n 

public Enumeration keys() { 


return Keys.elements(); 


) 


yx 
* Provide an Enumeration data structure for the elements Vector. 
* 


on 
pubDPse EBnumerstronvceremenss0 E 
Perurseyauesceltemenctsl 
> 


} // end of class NSGRepository 


// end of file NSGRepository.java 


Pie 


AML FILE 


APPENDIX E 


<?xml version="1.0"?> 


<!-- Simple XML file for use with the SOFT experiment  --» 
<!-- Note the hard-wired reference to the dtd. This should be fixed --> 
<!-- in order to run on another system --» 


SUDOCPYPESPRODOSOPGDESCRIRBTION SYSTEM 
Prile://74/paBAboecumentationv9dabp/protoeols/prorocoblSdeseripecron-sded^» 


See OOrl, PABP XML. PACKET DESCIPTICNS ==> 
SEROTOCODSDESCRIPITON» 
«PROTOCOL INFORMATION» 

«PROTOCOL NAME>SOFT</PROTOCOL NAME> 

«PROTOCOL _ MARKER _FIELD>PacketType</PROTOCOL_ MARKER FIELD» 
«PROTOCOL _ " MARKER _POSITION>0</PROTOCOL MARKER _ POSITION> 


<PROTOCOL MARKER_TYPE>org.web3d.vrtp.datatypes.UnsignedByte</PROTOCOL MA 
RKER_TYPE> 


SBROTIOCODOTYPESSPIOT- 
web3d. 


-PIPERO 
.web3d. 


SIYPR O 


Sven Ora: 
A BPE Org: 
SI PE Org. 
U PE Org. 
= IYEE>ore. 


web3d. 
web3d. 
web3d. 
web3d. 
web3d. 


Mp 
E 
aoc 
MECO: 
VED. 
VEC. 
E 


datatypes. 
datatypes. 
.SignedInteger</TYPE> 

.DoublePrecision</TYPE> 


datatypes 
datatypes 


datatypes. 
datatypes. 
datatypes. 


UnsignedByte</TYPE> 
uUnsignedShort</TYPE> 


array6</TYPE> 
arrayl6«/TYPE» 
array40</TYPE> 


«/PROTOCOL TYPE LIST» 


<!-- XXXX These fields are wrong! what should they be?! --> 
<PROTOCOL HANDLER>http: //www.stl.nps.navy.mil/~foo</PROTOCOL HANDLER> 


<PROTOCOL SEMANTICS HANDLER>demo.dabp.Semantics</PROTOCOL SEMANTICS HAND 
LER> 
</PROTOCOL INFORMATION> 
<ADUS> 
<!-- XFORM PACKET --> 
<ADU_DESCRIPTION> 
<ADU_INFO> 
<ADU _NAME>XFORM</ADU NAME> 
<ADU MARKER _VALUE>1</ADU | MARKER _ VALUE> 
«/ADU INFO» 
<EIELDS> 


<FIELD_PRIMITIVE> 
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<FIELD NAME>PacketType</FIELD NAME> 
<FIELD TYPE>0rng.wesed-vrcp. datatypes 
<FIELD DEFAULT>1</FIELD DEFAULT> 

< AETECD PRIMITIVE> 


<P LEEDS PRI Minn ie 
<FIELD | NAME»Tag«/FIELD NAME» 
<FIELD TYPE>0rg. websdi yr ip datan pes 
<FIELD DEFAULT>9</FIELD DEFAULT> 
c«/ELEBBEE PRIMITIVE» 


<FIEED PRIMITIVE> 
<FIELD NAME>CCode</FIELD NAME> 


<FIELD TYPE>org.web3d.vrtp.datatypes. 


<FIELD DEFAULT>0</FIELD DEFAULT> 
</ETELDE PRIMITIVE> 


<FIELD PRIMITIVE> 
<FIELD NAME>NodeName</FIELD NAME> 


<FIELD IYPE>0rg-web3d vrtp datatypes? 


SEDEDDS _DEFAULT>9</FIELD_ DEFAULT> 
7/7 TED PRIMITIVE> 


SEIEFPSERIMITIVES 
<FIELD NAME>mat</FIELD NAME> 


«FIELD TEP Org: wep od: vrtp.datatypes. 


<FIELD DEFAULT>9</FIELD DEFAULT> 
<7 DEO PRIMITIVE> 


</FIELDS> 
</ADU_DESCRIPTION> 


</ADUS> 
SAPDRBODOCODSDESCRPEITPONS 


purs 


-UnsIgneSPyEe</EIELDETZER> 


„arrayo</FTELDSTYPR> 


Sgnedinteger- /EIEIDER/ER- 


array40</FIELD TYPE> 


arrayl6</FIELD TYPE> 


APPENDIX F - DaBP CLIENTS 


Me nn ae non nn genen ce - 
// Filename: SClient.java 

// Date: 23-Aug-99 

1 Compiler: PEU. 

"p cec mE ee Ee eee a en ee 


import "org webs veurrdabp.; 
import org webs vrtpeou0tgl.*; 
import org.web>ad-vrtp.net.‘, 


import java.net.*; 
Import java.ıo.r, 
anmoort Java utiy 


/** 

=o Clare mt 

* 

* Simple client sending packets to the SOFT server. 

“iG is used for the empirical testing: 

* SClient uses SOFTexp.xml in order to create the protocol description. 
Then 

* it creates a byte array according to this protocol and sends this 
1000 times 

* to the server. The byte array contains the default data. 

* Syntax: SClient <server name> <server port> 

* 

* @author P.Fiabolis,G.Prokopakis 

7 
públic class Sela ent 

{ 


/** 
* Main method. Creates the protocol description, connects to the server 
and 
* sends an ADU 1000 times to him. 
* We need to add a time delay between sending packets. Whithout this 
delay 
* we get a NullPointerException exception (in the NSGServeOne) at the 
* ProtocolDescription.deterimineADUFromBinaryData method. 
A 
x 
public static veld main(String([] args) throws SocketException 
{ 
// args[0] = Server name 
// args[1] = socket number 


if(args.length != 2) { 
usageMessage(); 
System.exit(0); 
) 


ProtocolDesctriptrionVprobocol. 


Du 


ADUData packet; 


InetAddress addr; 

Socket socket; 
OutputStream os; 
DataOutputStream dos; 
ByteArrayOutputStream bos; 


DataOutputStream me; 
byte datal]; 


protocol = new PretocolDeseription( “S@blexp=.ml.):, 
packet = protocol.getADUDataForName ("XFORM") ; 


LEY 
{ 
addr = InetAddress.getByName(args[0]); 
System.out.printin("addr = " + addr); 
) 


catch (UnknownHostException uhe) 


( 


Svstem.out.printin( UnknowHMHlosto s 
return, 
} 
CEY 
{ 
socket = new Socket (addr, Integer.parseInt(args[1])); 


} 


catch(IOException ioe) 


{ 


System. out-printin ("Cannot create the socket c 
return; 
} 
BEY 
{ 
try 
{ 
os = socket.getOutputStream(); 


catch (IOException e) 
{ 


System.out.print In(”Conld- notierte zes output 


return; 
} 

» PrintStream p - new PrintStream( 
bos = new ByteArrayOutputStream ( 
dos = new DataOutputStream(bos) ; 
iy 

me = new DataOutputStream(socket.getOutputStream()); 
} 
catch(IOException ioe) { 
return; 


OS); 
) ° 


, 
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packet.serialize (dos); 
data = bos.toByteArray(); 


for ine 12-0; i < 120000; i++) 
{ 
E EY 
{ 
me.write (data); 
me.flush(); 


catch (IOException ioe) 
{ 
System.out.println("Could not write to the output stream 
a" + n 
return; 


) 
I end whale (crue) 


} 
finally 
{ 
SYSECM- CUE. pEIntel me Closimngmiel Tene eas 
try 
{ 
socket.close(); 
} 
catch(IOException e) 
{ 
SySeem.out.printin( Gould notsetose socket...) 
return, 


} 
} // end try-finally 


} // end main 


* Provides a hint message when the number of the command line arguments 
ES wrong. 


public static void usageMessage() { 


System.out.print("Usage: java SClient «server name»"); 
System.out9przmtin(' E 

System.out.peıntln(); 

System.out.printin("Exaple: java SClient venus 9000777 
System.out.printIn("\tvenus - machine running the SORT server"); 
System.out.println("Nt9000 - venus machine port"); 


} // end usageMessage 


)/ / end of classi o CI ent 


// end of file SClient.java 
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// Filename: RClient.java 
// Date: 23-Aug-99 
y C onpiler: JDK 1.2 


import org.web>d. vrep. .coebp. 7 
import, org.webid. vrrp-ucsı ei 
IMNBOLt- org. websarvrep.nee. , 


import java.net.*; 
impose ava.-io.*; 
inport Java util ; 


* 


RClient 


/ 


+ + + + + 


It is used for the empirical testing. 


Simple client reading packets from the SOFT server. 


* RClient uses SOFTexp.xml in order to create the protocol description 


Then, 


* it reads ADUs from the server. No packet processing takes place. 


* Syntax: RClient <server name> <server port> 
c 


* @author P.Fiabolis,G.Prokopakis 
2 

public class RClient 

{ 


/** 
* Main method. Creates the protocol description, 
and 
* reads ADUs from him. 
* 
+ 
publryc static void main(String margs) 
{ 
// args[0] = Server name 
// args[1] = socket number 


2E 
E 
E 


if (args.length != 
usageMessage ( 
System.exit (0 
} 


ProtocolDescription protocol, 
ADUData packet; 


InetAddress addr; 

Socket socket; 
OutputStream os; 
DataOutputStream dos; 
ByteArrayOutputStream bos; 


ADUStreamTCP tcpStream; 
ADUData data; 
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connects to the server 


protocol - new ProtocolDescription("SOFTexp.xml"); 
packet = protocol.getADUDataForName ("XFORM"); 


Eur y 

{ 
addr = InetAddress.getByName(args[0]); 
Systemoue printint"addr = " + addr); 

} 

catch (UnknownHostException uhe) 

{ 
Systemocub printin( "Unknown Hostes 
return; 


) 


Erw 
{ 


socket = new Socket (addr, Integer.parselnt (args[1])); 


} 

catch (IOException ioe) 

{ 
System.out.printlin("Unknewn I 
return, 


} 
tepotream = new ADUStreamICE(SOcket, protocol); 


try 
{ 
while (true) 
{ 
data = tcpStream.readNextADU (67); 
if(data != null) { 
Syoeem OUE. prine ue 
} 
} // end while (true) 
} 
finally 
{ 
ys tentolte print (closing elient 4); 
Ery 
{ 
socket.close(); 
} 
catch (IOException e) 
{ 


SVSEem- Out. printuat Could “net close socket: 


return. 


} 
) // end try-finally 


) // end main 


/** 


Te 


* Provides a hint message when the number of the command line arguments 


* is wrong. 


T23 


* 
KE 
public static void usageMessage() { 

System.out.print("Usage: java RClient <server name>"); 
System.out.println(" <server port>"); 
System.out printing? 
System.out.printin("Exaple: java RClient venus 9000"); 
System.out.println("\tvenus - machine running the SOFT server"); 
System.out.println("\t9000 - venus machine port"); 


} 


} // end of class RClient 


// end of file RClient.java 
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APPENDIX G - JAVA CODE FOR “PHASE FIVE” 


P pesce accu E 
// Filename: NSGServer.java 

// Date: 28-Aug-99 

Compiler S DE IM? 

A a a a ‘a a a 


import vorg websckvrtp.dabp. 
HEI Org websd vrp-utut. 


Import Java. net"; 


Import java. lo. 


/** 
* Main class for the NSG server. Enters an endless loop waiting 
Nor lente duesióse 
* 
= @autnhor B.RJabol1s,6.Prekepakıs 
E 
public class NSGServer { 


/* 

RAP» main function. 

* 

* @param args: Command line param. Should have the port number. 
* @exception IOException 

= 


public Static volrd main (String |) args) throws TIOExceptrionot 
PLOCOCOMPCSCLIDELON pECLocoL, 


if(args.length != 1) { 
usageMessage(); 
System.exit (0); 

} 


protocol= new ProtocolDescription(TSORTexp nl Ze 
Selversockee Server Socket, 
InetAddress addr; 


int Counter = I; 
EES 
server socket = new ServerSocket (Integer.parseiInt (args[0])); 


while(true) { 
Socket in socket = server socket.accept (); 


addr = in _socket.getInetAddress(); 
System.out.println("Welcome " + addr.getHostName()); 
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ie a 
new NScServeOne (11 „socket  eeumter nr, protocolli 
) 
catch (IOException e) { 
inwsgeket.cleseir, 
} 
} // end while 


) 

catch(IOException e) { 
System.out.printin("'Cannot initialize server. Ex ng EL 
System.exit (0); 

) 


} // end of main 


/* 
* Message to display in case of invalid command line arguments. 
* 
my 
public static void usageMessage() { 
System.out.println("Usage : java Server «port number»"); 


Svstem.out-prosmeljnmo v 
System.out.printin("Example: java Seryer, 99997 


} // end of usageMessage 
} // end of class NSGServer 


// end of file NSGServer.java 


N 
// Filename: NSGServeOne.java 

// Date: 20-Aug-99 

/7 Compiler, 23DK 1.2 

da a a ea ae eee 


import org-.web>d.yerrp - dappa 
import ordqoweb3sdo vEtp ubi 


Import Java o, 
Import Ja vane 

import java.util.Hashtable; 
import Java. útil Enumeration; 
import java.util.Vector; 


import java.util.Calendar; 
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/** 
* NSGServeOne 


* 
* An instance of this class is running for every client connected to 


the 
* NSGServer. Reads from an ADUStreamTCP stream. Each ADU is transformed 


TO 
* a byte array and retransmitted to the other clients currently 


connected. 
* 


* @author P.Fiabolis,G.Prokopakis 
2: 


class NSGServeOne extends Thread { 


/** 

* Unique ID for each thread. For the moment this is a simple counter 
E 

int threadID; 


/** 

* Stream where this thread will write the NSG's stored in the 
Deposıitory., 

KU 
OutputStream me; 


pex 

* Table holding the ports for all conected clients. Common for all 
threads 

27 


static Vector castTable = new Vector(); 


/** 

* Table holding SG data sent from clients. Common for all threads 
d 

static NSGRepository table - new NSGRepository(); 


/** 
* Semaphore for thread exit. 
E 


boolean stopThread = false; 


dod 

* Socket associated with this thread. 
x 

Socket threadSocket; 


/** 
* DaBP stream to read from. We can read ADUs directly from here. 
AA 

ADUStreamTCP tcpStream; 


{re 
* Represents one ADU read from the network. 
7 

ADUData data; 
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/* 

"IN SGservebne 

* 

* Class constructor. Initialize input and output streams, seda bP- 
client 

* to the client pool, and starts the thread execution. 

* A NullPointerException occurs after reading a number of packets 
(265€ 
Reason is not known for the moment but it is eliminated when a 
time delay is added to the sending client (SClient) between packet 
sending. 


+ + + + + + 


@param in socket: Socket for this thread connection 
@param id: unique ID for this client. For the moment just a counter 
* (exception 1OEzeeptjon 
5 
public NSGServeone (Socket In socket int id NU rotcocoiescTEN MEI 
DEOEOCOL) 
throws IOException { 


threadID - id; 
threadSocket - in socket; 


/* // try to increase the input buffer size 
System.out.println("Buffer size 1 = " + 
threadSocket.getReceiveBufferSize()); 


threadSocket.setReceiveBufferSize(threadSocket.getReceiveBufferSize() * 
EM 

System.out.perntlin("Butler sy2zo 2079 
threadSocket.getReceiveBufferSize()); 
SA 

me — new DataOutputStream(in socket.getOutputStream(í)); 


// Add the new comer tovtneselwene list. 
castTable.addElement (me); 


tepStream = new ADUStreamTCP (in socket, oro occa 


Start 


y * 

* Waits until a packet arrives. Then, it starts reading ADUs, stores 
them, and 

* retransmits them to the other clients. When done (1000 reads) 
calculates 


* the duration. 
bd 


ma 


Buble vola rum a 


int len = 0; 
OutputStream out; 
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Calendar begin, end; 

byte[] byteData; 

A 
// late-comer support not needed for this experiment. 
InputStream is; 


// Wait until there is something avilable to read. 
while(len == 0) 
( 
Ery 
{ 
is = threadSocket.getInputStream() ; 
len = is.available(); 
} 
catch(IOException ioe) 
{ 
System out Print in( Cannot Getvinput stredmo i; 
closeThread(); 
} 
} // end while(len == 0) 


// Start the»timer. 
begin = Calendar-getInstance(); 
System.out.println("Timer started... ); 


int counter = 0: 


while(!stopThread) 


{ 
try 


{ 
data = tcpStream. readNextADU (67); 


O 


Cay ET 
Object val = table.put (data.get ("Tag"), data); 


} 
catch (FieldNotFoundException ins a, 
System.out.printin("Rrieldmorzreundee 7: 


} 
Enumeration enum = castTable.elements(); 


byteData = data.getBinaryData(); 


while (enum.hasMoreElements()) { 
out = (OutputStream)enum.nextElement (); 
if (out != me) { 


out.write (byteData); 
} 
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} // end while 


COlnuLe 
if(counter >= 120000) { 
end = Calendar.getInstance(); 


long startTime = 
(begin.get (Calendar. HOUR) *60*60*1000) + 


(begin. get (Calendar.MINUTE) *60*1000) + 
(begin. get (Calendar.SECOND)*1000) + 


(begin.get (Calendar .MILLISECOND) ); 
long endTime = 
(end. get (Calendar.HOUR) *60*60*1000) + 


(end. get (Calendar.MINUTE) *60*1000) + 
(end.get (Calendar.SECOND)*1000) + 
(end.get (Calendar.MILLISECOND)); 


long duration = endTime - startTime; 
System.out.println("Duration = " + durationem 


System.out.println("Goodbye " + threadID); 
System.out.println("1000 packets read ..."); 
closeThread(); 


} 
y // end if 


} 

catch (IOException eee) 

{ 
System.out.printlIn ("Goodbye " + threadlD); 
System.out-printin(9Ccould notareadsnes ts... jy 
closeThread(); 


} 


ley /eend while Cine) 
} 
finally { 

closeThread(); 


} 


/* 
* Close the thread after finishing connection or failure. 
ry 
public void closeThread() { 
Gry 4 


threadSocket.close(); 
castTable.removeElement (me); 


130 


stopThread = true; 
} 
catch(IOException e) { 


System.out.println("ERROR: Could not close socket @ 
closeThread"); 


) 
) 
) // end NSGServeOne 


// end of file NSGServeOne.java 


131 





APPENDIX H —- JAVA CODE FOR TESTING CLIENTS 


Me HO See ee So SS EL CL nee 
// Filename: SClient.java 
// Date: 24-August-99 


¥/ Compiler: WR 1-2 
// Comments: Simple client sending packets to the SOFT server 
A Used for the empirical testing. 


import java.net.*; 
import java.io. 7 
Import Java- util- =; 


public class SCivent 
{ 
public static void main(String[] args) 
{ 
// args[0] = Server name 
// args[1] = socket number 


if(args.length != 2) { 
usageMessage(); 
System.exit(0); 
) 


InetAddress addr; 
Socket socket; 
FileInputStream fis; 
DataOutputStream dos; 


Ery 


{ 
addr - InetAddress.getByName (args[0]); 


System. out.printin(Taddr — "V PasudE 
} 


catch (UnknownHostException uhe) 


{ 
System. euer print ine. Unkneneerostarn oe 


return; 


} 


Ir 
{ 


socket = new Socket (addr, Integer.parselnt (args[1])); 


} 


-catch (IOException ioe) 


{ 


System.out.printin("Cannot create the socket ..."); 
Be un 


Ley 
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client. 


} 


// packet.exp contains a byte array extracted from a C++ 


// this packet corresponds to a transformation. 
fis = new FilelnputStream("packet.exp"); 


catch(FileNotFoundException fnfe) 


( 


) 


System.out.printin("File packet.exp rorzrfeundz 22 777 
Tee 
{ 


socket.close(); 


} 


catch (IOException ioe) 


{ 
) 


return; 


System. out. print\In("Can not close socket m 


byte[] b = new byte[65535]; 


Int 


try 
{ 


) 


len; 
len = fis.read(b); 
dos = new DataOutputStream (socket .getOutputStream()); 


for(int 1 = 0; i < 120000; i++) 
{ 

dos.writelnt (len); 

Gos writes, 0 len); 
} // end for 


System out. printla(" Donet); 


catch(IOExceptioniioe) 


{ 
} 
Ery 
{ 
) 


System.ouüt.println("Can not read ilen m 


socket.close(); 


catch(IOException ioe) 


{ 


) 


System. out. printin ("Can >not “close seckera, 9), 
return; 


} // “end main 


public static void usageMessage() { 
System.out.print ("Usage: java SClient <server name>"); 
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Svsteamseurt.println(" «server port» 

System out- println(); 

System.out.println("Exaple: java SClient venus 9000"); 
System.out.println("\tvenus - machine running the SOFT server"); 
System.out.println("Nt9000 = venus machine port"); 


) 


|o, end of 


V7 rlename: 


// Date: 


// Compiler: 
// Comments: 


// 


import java. 
import java.l 


class SClient 


RClient.java 

24-August-99 

TDK T 

Simple client receiving packets from the SOFT server 
Used for the empirical testing. 


— — X ee cr Anm cr dnm cm UD is Ai in ia is O E s As As diim e dim iium dium es es es ee ee es es es es es es ee diem ee es es ee es es es ee es ee ee ee es ae i oe s 


public class RClient 


{ 
{ 


public static void main(String [|pardgs) SthrowsSlOExcepion 


// args(0] = Server name 
// args[1] = socket number 


if(args.length ! 


} 


M 
usageMessage(); 
System.exit (0); 


InetAddress addr; 
Socket socket; 
DatalnputStream in; 


Grey 


{ 


} 


addr = InetAddress.getByName(args[0]); 
SVYoeome Out print lat addr TT 


catch (UnknownHostException uhe) 


MO 


} 


Cry 


{ 
} 


SYSTEM OU, print lu Un novn HOSE ESS 
return; 
socket = new Socket (addr, Integer.parselnt (args[1])); 
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catch (IOException ioe) 
{ 


System.out.printin( Cannot create wane socker E 
return; 


) 


byte[] b = new byte[65535]; 
int lens 


in = new DataInputStream (socket.getInputStream()); 


try 
{ 


while (true) 
{ 


len = in.readInt(); 
byte[] buf = new byte[len]; 
in.readEullv(buf, 0, len); 


} // end while(true) 


} 
finally 
{ 
UV 
{ 


socket.close(); 


} 


catch (IOException ioe) 


{ 


System.out.printin("Cangnee= clese socket =. |; 
return, 


} 


} // end main 


public static void usageMessage() { 


) 


System.out.print("Usage: java RClient <server name>"); 
System.out. printin(” <serven port); 
System. LT 

System.out.println("Exaple: java RClient venus 9000"); 
System.out.println("Xtvenus - machine running the SOFT server”); 
System.out.printein(” \e900C Me venus machine: porcul, 


YI enda RC lient 
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